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'Ine  X-Tree  research  project  [1]  is  an  attempt  to  design  a 
computer  system  composed  of  identical  single-chip  computers 
(X-Nodes)  connected  in  a hierarchical  structure.  Each  computer 
has  a processor  witn  a local  memory  and  is  connected  to  the  net- 
work via  an  intelligent  coinnuni cat ions  switcn  having  ports  at- 
tached to  a small  number  ot  adjacent  nodes. 

‘ilie  network  has  tlie  basic  form  of  a binary  tree,  altnough 
at  least  one  additional  link  to  tne  network  is  provided  to  s.nor- 
ten  inter -computer  message  paths  and  to  allow  fault-tolerance. 
As  tne  network  is  regular,  each  node  can  be  assigned  a unique 
number  and  a message  transmitted  tnrough  the  network  with  all 
routing  aone  locally  in  each  comuiiunications  switch  on  tne  patn. 

Tne  specific  network  structure  will  be  chosen  based  upon 
several  criteria: 

(1)  Minimum  message  path  length. 

(2)  Minimum  number  of  ports  per  node. 

(3)  Existence  of  a local ly-execu table  routing  algorithm. 
A large  number  ot  structures  have  been  studied  to  determine 

the  average  path  length  when  every  node  transmits  a message  to 
every  other  node  (2).  The  next  step,  following  this  'static" 
simulation,  is  to  simulate  the  operation  of  the  network  in  de- 
tail, acounting  for  message  interference.  This  requires  includ- 
ing the  effects  of  the  communications  switch  architecture,  the 
communications  protocols,  and  failures  of  nodes  and  links. 

This  report  concerns  the  development  and  implementation  of 
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a simulation  program  for  sucn  a study  of  tne  dynamic  operation  of 
the  network.  Tne  emonasis  is  on  tne  oesign  of  tiie  program,  witn 
simulation  results  used  as  examples  of  its  operation.  Ihis  re- 
port is  organized  into  'actions  concerning:  objectives  and  re- 
quirements of  tlie  study  (2),  simulator  design  considerations  (3), 
the  details  of  the  implementation  (4),  validation  procedures  (5), 
ana  a user's  iTuanual  (/Appendix  A). 

Results  of  studies  usina  tnis  simulator  will  be  used  in 
furtner  designs  of  tne  network,  tne  coraiunications  switches,  and 
routing  algorithms.  Ihe  simulator  may  be  extended  to  implement 
execution  of  toy  programs  for  operating  system  studies. 

Except  for  constructing  and  measuring  an  actual  system, 
simulation  is  the  best  way  to  determine  tne  behavior  of  the  sys- 
tem. Ihus,  as  much  simulation  as  possible  will  be  done  before 
building  a prototype  X-'iree.  inere  will,  however,  eventually 
come  a point  at  which  simulation  to  the  required  degree  of  detail 
becomes  too  expensive  and  an  actual  system  must  be  built  in  order 
to  learn  more. 
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'Ine  X-Tree  network  consists  of  a nu.ri)or  of  computers  con- 
nected via  bi-directional  cor.-i.unication  links  in  a binary  tree 

i 

structure.  As  Figure  1 shows,  additional  links  may  be  added;  tne 
structure  snown  is  calleu  a "lull-ring'  tree. 

i 

I For  purposes  of  simulation,  tne  essential  part  of  the  X- 

i Tree  network  is  tne  coirmunications  switcii  which  is  a component  of 

j 

■ every  X-Node  (Figure  2).  'ms  switcn  enables  messages  to  be 

transmitted  tnrough  tne  networK  witnout  tne  attention  of  tiie  CPUs 
along  the  paths.  ‘Ine  reguirc.i-ents  lor  tne  simulator  can  be 

I 

derived  by  examining  the  operation  of  tne  network  in  general  and 
of  tne  switcn  in  oarticular. 

! 

1 2.1.1  l-'.essages . (messages  in  X-'ireo  are  comruni  cat  ions  between 

j processes  residing  in  aifterent  processors.  Ihe  messages  may  be 

long,  as  witn  virtual  memory  pages  sent  from  a disk  at  the  bottom 
of  the  tree  to  a node,  or  short,  as  witn  requests  for  those 
pages.  (Jne  format  has  been  devised  to  cover  all  messages;  this 
format  has  routing  and  control  information  separate  from  the 
data.  The  routing  and  control  function  is  built  into  the 
I switches,  which  can  then  pass  the  data  without  examining  it. 

bach  rniessage  is  prefaced  by  a header  byte  and  a number  of 
\ address  bytes  (Figure  3) . Vvhen  a communication  switch  receives  a 
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new  iressage  over  one  ot  its  links,  it  can  insi-iect  the  address  and 
perform  a routing  algorithm  to  determine  wnich  link  to  send  it 
out.  An  arbitrary  number  of  data  bytes  can  then  follow  the  ad- 
dress. Finally,  a "teardown"  byte  will  terminate  the  message. 

2.1.2  Virtual  channels.  ^;any  messages  may  snare  the  sanie 
link(s)  for  part  of  their  paths.  If  a message  retains  total  con- 
trol of  u link  until  it  completes,  then  blocking  that  message 
blocks  all  the  links  on  its  patn;  deadlocking  of  the  network  can 
then  occur.  To  allow  use  of  a link  even  though  a message  through 
it  is  stalled,  the  virtual  channel  has  been  devised.  The  basic 
approach  is  to  buffer  parts  of  several  nessages  on  each  end  of  a 
link;  when  one  message  stalls,  another  is  transmitted.  The  vir- 
tual cnannel  is  similar  to  the  "circuit'*  defined  by  Tyme  [3], 
except  tnat  it  is  unidirectional. 

A virtual  channel  would  be  establisiied  for  messages  sent 
from  one  process  to  another.  Uhen  no  more  messages  are  to  be 
sent,  the  channel  is  released.  In  terms  of  Figure  3,  tiie  header 
and  address  establisn  the  virtual  channel,  the  data  blocks  would 
oe  separate  messages,  and  the  teardown  byte  removes  the  channel. 

2.1.3  CoiTimunications  switches.  Each  comur.unications  switch  has 
several  ports  anong  which  messages  are  passed;  one  port  goes  to 
the  node's  CfU,  the  other  ports  to  adjacent  nodes.  Ihere  is  also 
a communications  controller  (a  simple  processor),  to  route  mes- 
sages and  control  the  ports.  All  of  these  are  connected  via  a 
nigh-speed  bus  which  permits  full  conuiunication  while  preventing 
simultaneous  access  to  the  same  port. 
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Lach  port  has  two  separate  butter  structures  and  finite 
state  itiachines  for  control:  one  is  for  niessages  corring  in  frooi 
the  link  and  going  over  the  bus  to  another  port;  tne  otner  is  tor 
messages  from  the  bus  going  out  across  the  link  (Figure  A).  Lach 
buffer  has  a fixed  number  of  words  for  each  of  several  physical 
cnannels.  Bytes  sent  across  a link  from  tne  buffer  of  one  chan- 
nel are  stored  in  the  buffer  of  the  same  channel  on  the  other 
side.  ComiTiunication  in  the  opposite  direction  is  tne  same  for 
tnose  buffers.  The  bytes  sent  across  the  bus  are  storea  into  a 
different  pnysical  channel's  buffer  at  ttic  output  port.  The  out- 
put port  and  channel  had  been  previously  selected  by  tne  con- 
troller which  ran  tne  routing  algorithm  and  then  selected  an 
unuseu  cnannel  at  tnat  port.  Thus,  a virtual  channel  through  tne 
network  will  go  tnrough  different  physical  channels  at  each  link. 


2.1.4  Controller  operation.  Unen  a message  arrives  at  an  input 
port  tnrough  an  unused  channel,  it  is  stopped  until  tne  controll- 
er can  service  it.  The  first  part  of  the  message,  the  header  and 
address  bytes,  are  then  sent  into  tne  controller  as  they  arrive, 
hnen  all  of  the  aduress  nas  arrived,  the  controller  can  perform 
the  routing  algorithm.  It  then  selects  an  unused  physical  chan- 
nel at  that  port  and  transmits  the  header  and  address  to  it. 
.\hen  that  is  finished,  the  controller  modifies  a control  table  at 
the  input  port  to  cause  that  channel  to  be  sent  directly  to  the 
selected  output  port  and  channel. 


2.1.5  Input  port  operation.  An  input  port  will  thus  have 
several  active  physical  channels.  The  interport  bus  is  run  on  a 
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fixecj  tin«  slot  basis:  onc-3  each  time  around,  eacn  input  port 
will  be  able  to  transter  a data  byte  from  one  channel's  buffer  to 
the  output  port.  The  task  of  tne  finite  state  machine  at  the 
port  is  then  to  select  a channel  for  intra-node  transmission. 
Generally,  it  will  send  consecutive  bytes  from  one  channel  until 
either  the  butler  runs  ary  or  the  output  buffer  fills  up  and 
rejects  a byte.  The  IdM  tnen  goes  to  tne  next  channel  with  data 
in  its  buffer. 

alternative  strategy  would  be  to  go  to  a new  channel 
after  each  byte,  to  avoid  overflowing  the  receiving  buffer.  Doth 
of  tiiese  techniques  will  be  investigated. 

2.1.6  Output  port  operation.  The  output  ports  function  very 
similarly,  selecting  a channel  for  transmission  and  then  sending 
as  many  bytes  as  possible.  'Tne  difference  is  that  since  only  one 
byte  can  be  sent  at  a time  across  tne  link,  the  channel  nu.mber 
cannot  be  sent  in  parallel  with  the  data,  as  it  can  across  the 
ous.  Thus,  when  beginning  a new  channel,  tne  channel  number  is 
sent  first  and  then  the  aata  bytes. 

Link  protocol.  Tne  two  output  ports  sharing  a link  may 
both  desire  to  send  at  the  same  time.  A small  amount  of  logic 
and  soiTv:  x)ntrol  lines  can  resolve  this  contention;  the  effect  is 
that  when  botn  have  data  to  send,  they  will  alternate  byte  by 
byte.  This  is  independent  of  whetner  a channel  number  or  data 
oyte  is  being  sent. 

2.1.8  Cnannel  tear^^.  When  one  process  no  longer  desires  to 
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send  to  another  it  can  transmit  a special  teardown  byte  along  tne 
virtual  channel.  Lach  input  port  recognizes  the  byte  and,  after 
transmitting  it  to  tne  output  port,  disables  the  physical  channel 
so  that  the  next  data  received  on  it  is  sent  to  the  controller. 

In  suntmary,  processes  coinnunicate  via  unidirectional  virtu- 
al channels  which  they  set  up  when  needed  and  tear  down  when  no 
longer  needed.  These  channels  are  set  up  by  sending  a header  and 
address  from  source  to  destination.  At  each  node  on  the  path,  a 
routing  algorithm  is  executed  and  a pointer  established  from  the 
physical  channel  at  the  input  port  to  the  piiysical  channel  at  tne 
output  port.  As  many  data  bytes  as  desired  are  then  sent  along 
the  virtual  channel.  Finally,  a teardown  byte  is  sent,  removing 
the  links  between  physical  channels,  thus  renoving  tne  virtual 
Channel. 

2.2  Objectives 

Tne  purpose  of  the  dynamic  simulation  is  to  determine  the 
feasibility  of  tne  X-Tree  concept  in  general  and  of  the  conitiuni- 
cations  scneme  in  particular  The  success  of  X-Tree  will  larqely 
depend  upon  its  ability  to  transmit  internode  messages  rapidly. 
The  design  of  the  conmuni cat ions  switch  will  thus  require  accu- 
rate statistical  information  about  the  performance  of  various 
structures  under  Different  workloads. 

2.2.1  ffesign  information.  The  design  of  siirxgle-chip  computers  is 
in  some  sense  reversing  the  trend  of  recent  years  toward  cheap 
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hardware.  On  the  chip  surLace,  tne  silicon  (or  whatever  irateri- 
al)  "real  estate"  is  precious;  tne  iraxiirum  function  must  be  ob- 
tained from  a limited  area.  Off-chip  corranunication  is  now  rela- 
tively expensive:  drivers  consume  much  area  and  are  slow.  The 
pins  also  represent  a prine  source  of  failures. 

This  leads  to  some  design  principles:  oft -chip  communica- 
tion must  be  minimized  (aided  by  powerful  processing  on-chip), 
pinouts  must  be  kept  as  few  as  possible,  and  tlie  on-chip  area 
dedicated  to  co.iiiTiunications  must  be  minimized.  These  in  turn 
suggest  the  classes  of  information  which  tlie  dynamic  simulation 
must  deal  witi:. 

The  message  buffers  within  tne  switch  should  be  minimized 
to  allow  more  area  for  the  CPU.  This  problem  has  (literally)  two 
dimensions:  the  number  of  bytes  per  channel  gives  the  width  of 
the  butter  and  the  numoer  of  channels  gives  its  height.  If  only 
a small  nunber  of  channels  in  each  port  is  used,  the  buffer 
height  can  be  limited.  If  tew  of  the  enabled  channels  are  ever 
busy,  tnen  the  interprocess  conuiiunication  algorithms  can  be 
designed  to  release  idle  channels  more  frequently.  Finally,  if 
buffering  only  a small  number  of  bytes  per  channel  causes  little 
degradation,  the  buffer  length  can  be  reduced. 

Message  routing  algorithms  need  to  be  tested  under  condi- 
tions of  faults  and  congestion.  Algor itnms  tor  the  same  struc- 
ture should  be  carefully  compared  rsefore  one  is  designed  into  the 
silicon. 

2.2.2  §E?citic  data.  Designing  the  system  will  require  compar- 
ing the  performance  of  different  structures  under  various 
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workloads.  Singulations  will  yield  pertorirance  indices  £or  dif- 
ferent system  and  workload  variables.  System  variables  are  tne 
network  structure,  routing  algorithm,  buffer  sizes,  and  fault 
patterns.  Structures  will  be  essentially  binary  trees  with  one 
or  two  extra  links  per  node.  Various  interconnection  schemes  can 
be  devised  for  the  extra  links,  and  each  scheme  must  have  a rout- 
ing algorithm.  Duffer  size  includes  both  the  number  of  physical 
channels  and  the  buffer  lengths.  Lengths  might  not  be  the  same 
for  both  input  and  output  ports.  Faults  include  both  broken 
links  and  disabled  nodes. 

/orKload  variables  reflect  the  lengths,  generation  frequen- 
cy, and  paths  of  the  messages  sent  within  the  network.  eage 
traffic,  between  leaves  and  other  nodes,  will  be  long,  relatively 
infrequent  messages.  Short,  more  co;Tiiion,  interprocess  messages 
may  be  sent  between  any  nodes,  ilessage  generation  will  eventual- 
ly be  aetermincj  by  execution  of  a trace  program,  where  receiving 
a iressage  alters  the  state  of  a node,  changing  its  generation 
pattern.  Such  a program  woulo  be  designed  to  generate  message 
I traffic  similar  to  that  of  an  actual  program. 

i Performance  indices  indicate  how  well  messages  flow  a,nd  the 

; degree  of  hardware  utilization.  The  basic  index  is  the  total 

j transmission  time  of  a message  with  respect  to  its  length,  path, 

! ahd  the  loadihg  of  the  network.  Ihe  number  of  consecutive  bytes 

transmitted  between  rejections  is  a measure  of  the  degree  of  mes- 
! sage  interference.  The  number  of  active  channels  and  the  buffer 

I occupancy  give  the  hardware  utilization.  Finally,  the  distribu- 

tion of  traffic  over  the  network  should  be  studied  to  identify 
bottlenecks. 


2 . 3 Requirements 


The  key  to  tne  implementation  ot  the  simulator  is  the  flex- 
ibility to  permit  accurate  measurement  for  widely  different  con- 
ditions. The  representation  of  system  and  workload  variables 
must  allow  untoreseen  additions  while  the  representation  of  per- 
formance must  allow  measurement  of  new  indices,  all  with  minimum 
modification  to  the  simulator. 

Tne  program  must  be  easily  expandable  to  permit  adding  new 
structures  and  routing  algorithms  which  will  certainly  be  devised 
after  the  simulator  is  written,  piore  sopnisticated  message  gen- 
erators will  bo  added,  eventually  to  include  toy  program  execu- 
tion. 

The  simulator  must  be  usable  and  modifiable  without  requir- 
ing that  the  user  know  its  every  detail.  Finally,  execution 
should  be  reasonably  fast  to  permit  long  sirrolations. 
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3 DLoIGl'i  CUi«bl  DLlvA'I'iONo 


Tills  portion  of  die  report  enuoierates  and  cot, pares  the  pos- 
sible inethods  of  impleTonting  the  simulator.  In  tne  subsequent 
section  on  iniplementation,  these  considerations  are  applied  to 
X-Tree  in  particular. 

3 . 1 General 

The  most  basic  decision  is  the  level  at  which  to  simulate 
the  network.  The  least  detailed  is  the  implementation  of  some 
analytic  function  (or  set  of  functions)  describing  a model  of  the 
network  or  some  aspects  of  it.  'ihe  most  detailed  would  represent 
the  complete  state  of  each  node  to  the  level  of  programs  in 
memory.  The  tradeoffs  involve  accuracy  and  validity  versus  run 
time  and  memory  usage. 

Implementation  of  an  analytic  model  uses  the  least  time  and 
memory,  but  requires  many  simplifying  assuir,ptions.  These  assump- 
tions limit  tne  domain  of  validity  of  the  model  — what  is  true 
for  ligntly-loaded  networks  m.ay  not  hold  when  the  traffic  in- 
creases. In  the  case  of  the  X-lree  network,  models  do  not  yet 
exist  for  any  cases,  although  this  simulator  will  aid  in  develop- 
ing them. 

Representation  of  the  complete  network  state  is  not  possi- 
ble, either,  given  the  uncertainties  of  the  CPU  design  and  the 
size  of  the  network.  Going  to  too  great  a degree  of  detail  is 
not  worthwhile,  as  the  network  will  operate  asynchronously,  thus 
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invalidating  an  eftectiveiy  synchronous  siniulation.  iiowever,  if 
the  detail  is  sufficient,  tnen  a variety  of  structures  and  work- 
loads can  be  tested  without  affecting  the  validity.  If  the  simu- 
lator functions  like  the  actual  network,  then  its  operation  can 
be  traced  as  would  that  of  an  actual  system. 

The  functions  performed  by  the  simulator  are:  emulating 
the  actual  operation  of  the  network,  monitoring  the  operation, 
and  statistically  summiar izing  certain  aspects  of  the  operation. 
These  can  be  carried  out  in  essentially  three  different  ways. 

3.2.1  Cata  base  approach.  A common  technique  in  performance 
measuremient  of  existing  computer  systan  is  to  produce  trace  tapes 
to  be  stuoied  off-line.  In  an  analogous  fashion,  a simulator  can 
produce  a stream  of  trace  messages  to  be  stored  in  a data  base 
(4,'.  If  tne  trace  is  detaileo  enough,  then  the  data  from  a sin- 
gle run  will  be  useful  for  statistical  studies  of  different  per- 
formance indices,  not  all  of  which  iray  be  foreseen  at  the  time 
the  sim.ulator  is  designed.  Tne  problem  with  the  data  base  tech- 
nique is  that  the  amount  of  data  produced  can  be  enornxaus. 

3.2.2  Direct  a£)aly§is  approach.  The  opposite  approach  is  to 
intertwine  tne  statistics  processing  with  the  actual  simulation, 
and  eliminate  the  trace  output.  This  removes  the  need  for  a 
large  data  base  and  can  produce  tne  final  data  quicker  and 
without  having  to  coordinate  the  simulator  and  a statistics 


13 


I 


program.  However,  tnis  lacks  flexibility:  detailed  reprogram- 
ming is  needea  to  measure  any  but  the  standard  indices.  Tnis 
revised  program  must  then  be  retested. 

^•2- 3 Mixed  approach.  Tb  avoid  tne  size  problem  of  tne  data 
base  while  retaining  its  flexibility,  the  trace  can  be  feci 
directly  into  the  statistics  program,  if  tiie  operating  system 
under  which  tne  simulation  is  running  permits  this  (e.g.:  the 
UMX  pipe  mechanism).  As  in  the  data  base  technique,  the  user 
must  prepare  the  statistics  program  to  accept  a stream  of  stan- 
dard trace  messages  and  from  them  derive  the  desired  information. 
The  disadvantage  is  that  the  complete  simulation  .must  be  rerun 
each  time  a new  statistics  routine  is  run. 

3.3  User  Interaction 

Curing  the  initial  debugging  and  validation  and  later  when 
a new  user  is  learning  to  use  the  simulator,  it  is  convenient  for 
it  to  run  in  an  interactive  manner.  This  requires  prompting  for 
input  para.meters  and  checking  them  for  correctness  as  well  as 
producing  intelligible  trace  messages.  Cebugging  tools  should 
also  be  added  to  allow  the  user  to  see  in  detail  tne  state  of  the 
simulation.  Tools  external  to  the  simulator  may  also  be  used  to 
measure  code  and  data  space  and  execution  time. 

There  are  a number  of  more  specific  issues  which  must  be 
considered;  these  will  be  discussed  in  tne  next  section,  on  im- 
plementation. 
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4 IMPLU-'u-JlMION 


Tnis  part  of  the  report  is  concerned  with  the  details  of 
the  implementation.  Keferences  are  n.ade  to  portions  of  the  simu- 
lator and  statistics  program  code  which  are  in  Appendices  E and 
C.  .'dth  this  information,  a user  should  be  able  to  modify  the 
simulator  to  deal  with  any  desired  structure,  workload,  or  sta- 
tistical summary. 

4.1  ^neral 

The  simulator  is  a version  7 C prajram  running  on  the  U.  C. 
Berkeley  LLCd  Unix  system  on  a PUT  11/7^.  It  is  a discrete-time 
simulation  in  which  the  tiri,e  quantun,  or  tick',  represents  tne 
time  for  one  byte  to  be  sent  across  an  internode  link.  This  is 
also  the  time  for  one  cycle  tnrough  all  the  time  slots  of  the 
interport  bus  within  tne  conniunication  switch,  fvather  than  main- 
tain a time-oruerea  event  list,  requiring  the  overhead  to  insert 
entries,  tne  simulator  at  each  tick  searches  through  all  the 
nodes,  operating  upon  those  that  are  active  at  that  tick.  This 
will  be  further  explained  below. 

The  sim.ulation  process  is  partitioned  into  a sin.ulator 
which  produces  a trace  of  events  in  the  network  and  a 
statistics-gathering  program  wnich  reads  the  trace  and  compiles  a 
suiTrary  of  the  network's  behavior.  While  the  simulator  can  be 
used  to  produce  a data  base,  it  is  expected  that  most  users  will 
pipe  tne  output  directly  into  a statistics  program  to  avoio 


producing  a large  data  base. 


^•2  Simulator 

Ine  simulator  nas  two  phases:  an  initialization,  in  which 
the  system  and  workload  parameters  are  input,  and  the  actual  run, 
in  wnich  messages  are  iioved  and  the  trace  is  output.  In  each 
tick  ot  the  run,  the  simulator  makes  two  passes  across  all  of  the 
nodes  and  ports.  'IVie  first  pass  locates  and  marks  ports  having 
data  to  send  and  the  sec  )nd  iroves  one  byte  from  each  of  those 
ports.  Separate  passes  are  needed  to  prevent  any  byte  from  being 
moved  more  than  one  steo  in  one  tick. 

4.2.1  Cata  repres^tation.  ine  data  structures  fall  into  four 
classes  corresponding  to  the  major  elements  of  the  sytem:  nodes, 
ports,  physical  channels,  and  messages.  An  X-lree  is  represented 
as  an  array  of  nodes,  with  each  node  having  a controller,  CPU, 
and  an  array  of  ports.  Lach  port  has  an  input  and  an  output  sec- 
tion, each  having  a pointer  to  a list  of  currently  active  chan- 
nels. A channel  has  counters  representing  buffers  on  eacn  end  of 
a link;  it  would  be  conceptually  more  direct  to  put  fixed-size 
arrays  in  each  port  to  represent  the  multi-channel  buffers.  How- 
ever, this  would  require  much  storage,  of  which  relatively  little 
would  be  active;  the  linked  list  approach  conserves  space.  Fi- 
nally, each  message  is  passed  by  means  of  pointers;  just  as  one 
actual  message  will  occupy  buffers  in  several  channels,  several 
simulated  channels  will  have  pointers  to  the  same  inessage.  A 
typical  link  and  its  adjacent  ports  are  shown  in  Figure  5a  and 
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tns  corresponding  simulated  ports  and  channels  in  Figure  5d.  Ihe 
declarations  of  these  structures  are  on  page  B-1  (of  the  simula- 
tor code) . 

Nodes.  To  represent  the  controller,  each  node  has 
a counter  'conbuf"  of  the  number  of  address  bytes  in  the 
controller's  buffer.  There  is  also  a queue  of  channels  waiting 
to  send  addresses  to  the  controller;  the  queue  is  managed  with 
pointers  "waithead  and  ' waittail  . The  CPU  is  represented  by 
the  pointer  "cpoutchnl"  to  the  channel  which  is  currently  sending 
data  over  the  link  from  the  CPU.  Conditions  in  the  node  in- 
clude: node  alive  or  dead,  controller  receiving,  CPU  sending 
Channel  number,  and  last  byte  from  CPU  rejected,  inese  are  en- 
coded as  one-bit  flags  in  "nflag  . This  requires  a total  of  13 
oytes. 

Flags  for  tx)th  nodes  and  rxjrts  are  encoded  into  character 
variables  with  one  bit  per  item.  A specific  bit  is  tested  by 
ANDing  the  flag  with  an  octal  constant.  A bit  is  set  by  OPing 
with  a constant  and  reset  by  /Vd'Ding  with  the  complement  of  that 
constant.  The  formats  of  these  flags  are  snown  in  Figure  6. 

In  the  tree,  nodes  are  narbered  beginning  with  "1"  (the 
root).  As  C numbers  arrays  beginning  with  "0",  the  first  element 
of  the  node  array  will  be  unused.  Tnus,  tlie  constant  "NCDEt-lAX' 
is  always  one  greater  than  the  maximum  allowable  nuitber  of  nodes. 

4. 2. 1.2  ^rts.  The  ports  are  nambered  from  zero  to  "port- 
num".  Zero  through  two  are  the  ports  to  parent,  left  child,  and 
right  child,  respectively.  Port  "portnum'  is  the  port  to  the 
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CPLI.  Other  ports  are  defined  according  to  the  structure.  The 
output  section  of  each  port  has  a pointer  "outchnl ' to  the  chan- 
nel currently  sending  data  across  the  link  £ind  a queue  ("qhead 
and  "qtail")  of  messages  awaiting  a free  channel.  Ihe  input  sec- 
tion has  a pointer  "inchnl"  to  the  channel  currently  sending  data 
across  the  bus.  Tne  counter  ' chnls"  gives  the  numJaer  of  output 
Channels. 

Status  inforiraticn  in  'uflag  ' tells:  if  the  port  has  been 
checked  by  "passl",  if  tlie  output  is  sending  a channel  number  or 
a data  byte,  if  the  CPU  is  sending,  and  for  both  input  and  out- 
put, if  the  port  is  sending  and  if  tne  last  byte  was  rejected, 
ine  pointer  ''link"  is  to  the  port  across  the  link,  and  'prnode" 
is  to  the  node  of  which  the  port  is  a part;  this  node  pointer 
speeds  up  references  to  other  ports  in  the  no-de.  Lacn  port  re- 
quires 15  bytes. 

4. 2. 1.3  Channels.  Uach  channel  has  an  output  buffer  "out- 
buf"  and  an  input  buffer  "inbuf*.  These  are  checked  for  ever  flow 
against  the  global  "outbuflim  and  inhuflim  . There  is  a 
pointer  "destc"  to  the  output  channel  to  which  the  input  is  send- 
ing; if  the  channel  is  waiting  for  the  controller,  this  field  is 
a link  to  the  next  channel  in  the  waiting  list.  The  pointers 
nexte"  and  'lastc'  are  used  to  form  the  circular  list  of  active 
channels.  'Ihe  input  status  is  in  "cflag ' ; the  channel  can  be 
waiting  for  the  controller,  sending  to  the  controller,  or  sending 
to  an  output  port.  This  requires  11  bytes.  Figure  7 illustrates 
the  organization  of  channels  in  a node. 
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4. 2. 1.4  f-essaqes.  To  be  routed  and  passed  properly,  each 
t message  contains  a destination  node  nunber,  number  of  address 

bytes,  total  number  of  bytes,  and  teardown  / regular  indicator. 
To  permit  a useful  trace,  each  also  has  a start  time  and  a count 
of  the  number  of  comniiunication  switches  it  has  passed  through.  A 
pointer  to  another  message  allov^s  it  to  bo  queued.  Each  message 
structure  is  12  bytes. 

4. 2. 1.5  descriptors.  A final  structure  is  the  message 
descriptor,  which  contains  the  generation  frequency,  address  and 
total  lengths,  and  a path  description.  All  nodes  generating  the 
same  kind  of  message  have  a pointer  to  tne  same  descriptor.  Each 
descriptor  is  13  bytes. 

In  each  structure,  character  variables  have  been  used  when 
possible  to  reduce  the  size  of  the  structure,  inis  is  of  partic- 
ular importance  in  the  channels  because  of  their  largo  number. 

4.2.2  Initial izat^n.  Ihe  system  and  workload  variables  are  set 
by  tne  user  during  execution  of  the  ''initialize'  routine.  The 
routine  will  prompt  in  Englisn  for  pa, ameters  unless  the  "-s" 
(suppress  prompt)  arguirent  is  given  when  tne  simulator  is  called. 
Each  para.T.eter  is  read  in  and  checked  for  validity;  e.g.,  node- 
num",  che  number  of  nodes  in  the  tree  being  simulated  cannot  be 
greater  than  "NCDE^'AX",  the  number  of  nodes  in  the  array.  The 
system  variables  specified  are  ''nodenum  , 'inbuflim',  'out- 
buflim',  "shape'  (the  network  structure),  and  "rtalgo"  (the  rout- 
ing algorithm). 
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Tne  structure  is  specified  by  setting  the  'link's  in  each 
port.  The  links  ore  set  by  using  the  function  "otherport"  which 
returns  a pointer  to  the  attach-ed  port,  "otherport"  uses  the 
function  "othernode ' to  find  tne  number  of  the  attached  node. 
The  nuiTter  of  ports  is  set  according  to  the  structure,  'where  it 
is  possible  to  specify  links  algorithmically,  tne  user  should  add 
a case  to  the  switch  to  perform  this. 

For  fault  tolerance  studies,  nodes  and  links  can  be  expli- 
citly killed.  A dead  node  has  its  alive  flag  set  to  zero  and  the 
links  in  adjacent  nodes  also  set  to  zero.  A dead  link  has  "link" 
set  to  zero  in  both  of  the  linked  oorts. 

Workloads  are  specified  by  creating  message  descriptors  and 
sotting  pointers  to  Uiem  in  the  no-des  concerned. 

Specific  parameter  input  forirats  are  given  in  the  User's 
Manual,  Appendix  A. 

4.2.3  F^s  oiie.  The  procedure  ' passl ' is  used  to  mark  the  ports 
which  will  be  sending  in  the  current  tick.  It  is  called  from 
run'  for  each  port  which  is  not  yet  visited  and  which  has  a 
nonzero  link.  Tnis  test  is  put  outside  the  procedure  call  to 
eliminate  the  calling  overhead  if  no  further  action  would  occur. 

In  "passl'  botn  tne  current  port  and  tne  port  attached  via 
the  link  are  processed  and  then  marked  as  visited.  First,  the 
input  sections  of  the  ports  are  processed  as  follows;  if  there 
is  a channel  on  its  list,  then  if  there  is  more  data  to  send  and 
the  last  byte  was  not  rejected,  tne  port  is  set  to  send.  Other- 
wise, the  function  "findinchnl'  searches  the  list  for  the  next 
channel  with  data;  it  one  is  found,  the  port  is  set  to  send;  if 
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none  with  data  is  found,  tne  i^ort  will  not  send.  Finally,  tne 
reject  flag  is  cleared. 

Tne  output  port  is  processed  in  a similar  manner,  except 
that  if  a new  channel  is  selected,  the  ''sending  channel  number  ' 
flag  is  also  set.  The  output  port  across  tne  link  is  then  pro- 
cessed identically;  if  both  outputs  want  to  send,  the  contention 
for  the  link  is  resolved  by  turning  off  the  port  which  sent  dur- 
ing the  last  tick.  If  the  processed  port  was  to  the  CPU,  then  a 
separate  section  of  code  is  executed,  to  deal  with  the  different 
pointers. 

If  the  controller  is  idle  and  tnere  is  a channel  waitim 
for  it,  that  channel  is  enabled.  Finally,  both  ports  are  marked 
as  visited  by  "passl’.  Ttiis  prevents  reprocessing  the  other  link 
when  its  node  is  visited. 

4.2.4  G^eration.  After  all  of  the  ports  in  each  node  have  been 
processed,  'generate"  is  called  if  the  node  nas  a message 
descriptor.  Depending  upon  tiie  kind  of  descriptor,  a .message  may 
be  generated.  If  one  is,  then  a channel  is  created  from  the  Cil) 
ana  a pointer  set  in  that  channel  to  t3ie  generated  message. 

4.2.5  Pass  tw.  In  "pass2  ' , tiio  active  ports  have  bytes  moved 
from  them.  'pass2'  is  called  from  "run*  if  either  the  input, 
output,  or  CPU  output  port  is  sending.  First,  the  output  ports 
are  processed;  if  the  "sending  channel  number"  flag  is  set,  no 
byte  is  moved  in  order  to  to  simulate  that  overhead.  Otherwise, 
if  there  is  room  in  the  input  buffer,  a byte  is  moved  by  incre- 
menting "inbuf"  and  decrenenting  "outbuf".  If  there  is  no  room, 
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nothing  moves  ana  the  reject  flan  is  set.  iiowever,  if  the  port 
was  to  the  CPU,  the  byte  will  alv/ays  be  accepted  — this  simu- 
lates a Ci-'A  channel  to  tne  X-Uode's  (relatively  large)  memory. 
If  tne  byte  sent  was  the  last  of  the  message,  a trace  message  is 
output;  if  the  message  was  also  a teardown,  the  slot  is  reimoved. 

The  input  port  is  processed  next.  If  tne  channel  is  wait- 
ing for  the  controller,  it  is  rejected.  If  it  is  sending  to  tne 
controller,  the  byte  is  moveo.  If  that  was  the  last  byte  of  the 
address,  the  message  is  routed  and  a channel  is  created  at  the 
selected  output  port.  If  the  input  port  is  sending  to  an  output 
port,  the  byte  is  noved,  subject  to  being  rejected  by  the  output 
port.  The  numljer  of  active  channels  at  a port  is  not  explicitly 
limited. 

Next,  if  this  is  the  CPU  port,  and  tne  CPU  is  sending,  a 
byte  is  moved  as  with  tne  output  oort  above.  Finally,  if  a mes- 
sage is  generated,  a channel  is  created  from  tne  CPU. 

4.2.6  Trace  messages.  'Ihe  messages  output  by  the  simulator  fall 
into  three  classes:  run  para.meter.s,  primary  trace  data,  and 
secondary  trace  data.  Generally,  a message  is  output  only  if  an 
event  occurs;  if  a port  is  idle  no  !ix?ssage  will  l>e  generated  to 
describe  its  state.  This  approach  reduces  the  amount  of  output 
done  by  the  simiulator. 

Some  run  parameters  are  the  system  and  workload  variables, 
wliich  are  echoed  by  the  initialization  routine.  Other  such  mes- 
sages indicate  tne  start  and  end  of  a run,  tjie  current  tick,  and 
exhaustion  of  free  lists  of  messages,  message  descriptors,  and 
Channels.  These  messages  are  used  by  the  statistics  program  to 
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ada^t  itself  to  tne  particular  s/stem  being  sin-.ulated. 

As  was  discussed  in  the  requireirents , the  basic  perfor- 
mance indices  are  message  transmission  time,  consecutive  bytes 
sent,  channel  usage,  and  buffer  occupancy,  lliese  data  are  given 
by  the  primary  trace  messages.  The  transmission  time  is  given 
when  each  message  is  completely  received  at  its  destination.  Tlie 
nunber  of  consecutive  bytes  sent  from  each  CPU  is  output  each 
time  a byte  from  tne  CPU  is  rejected.  (Transmission  of  the  chan- 
nel nuiTiber  is  not  counted.)  tach  time  a channel  is  added  at  a 
port,  the  total  number  of  channels  there  is  output.  Buffer  occu- 
pancy is  not  measured  directly  — the  frequency  of  rejection  can 
indicate  tiiis.  Constantly  outoutting  the  numiber  of  bytes  in  each 
buffer  would  be  possible,  but  slow. 

The  secondary  trace  messages  provide  more  detailed  data 
about  the  operation  of  the  network.  'Ihis  includes  transmission 
of  individual  bytes,  contention  tor  links,  starting  transmission 
on  a new  channel,  and  creation  of  a new  channel.  Tne  reject  mes- 
sage mentioned  above  can  be  used  with  the  new  channel  message  to 
determine  now  many  channels  at  a port  have  data  to  send. 

4 . 3 Statist i cs  Pr ©■g r am 

It  is  expected  that  the  user  of  the  simulator  will  write 
his  own  statistics-gathering  program  to  produce  Uie  information 
he  desires.  TO  indicate  one  approach  and  to  provide  some  initial 
data,  a statistics  program  is  provided  in  Ap[x?ndix  C.  This  pro- 
gram is  des: jned  to  produce  three  kinds  of  information:  average 
transmission  timie  as  a function  of  distance,  channel  usage  sorted 
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by  nu.rJDer  of  channels  used,  and  consecutive  bytes  transmitted 
^ from  CPUs,  sorted  by  number  of  bytes  sent.  Ihe  statistics  pro- 

I gram  is  in  Appendix  C. 

4.3.1  Transmission  times.  As  «as  stated  in  tne  requirements, 
the  primary  performance  index  of  tne  network  is  the  time  requirca 
tor  messages  to  be  transmitted  as  a function  of  their  size  and 
path  length,  for  this  statistics  program,  all  messages  are  as- 
suiiied  to  be  of  uniform  length.  Lach  message  carries  witn  it  a 
count  of  the  numiber  of  co.7uiunication  switches  it  has  passed 
through  as  well  as  the  time  at  which  it  was  generated.  The  data 
structure  used  has  two  counters  for  each  patn  length  from  zero  to 

(I  nine  ('time"),  when  a message  arrives  (indicated  by  an  'a'  trace 

ixessage) , its  total  travel  time  is  added  to  "time(i].timesum  , 
j where  'i"  is  the  path  length.  The  number  of  messages  having  tnis 

j path  length  ("time[i)  .msgnum.  ) is  then  incremented.  hhen  the 

simulation  is  over,  the  average  transmission  time  for  each  path 
' length  is  co..iputed  and  output. 

\ '^•3*2  Cnannol  usage.  A distribution  of  the  numbers  of  active 

! channels  at  each  port  is  produced.  Lach  time  a message  is  rout- 

; ed,  a 'q'  trace  message  is  output,  containing  the  new  number  of 

I active  channels  at  the  input  port.  Tne  statistics  routine  keeps 

the  maximun  number  of  active  channels  at  each  port,  increasing 
5 the  count  when  a 'q'  message  with  a greater  count  arrives.  After 

> the  simulation  ends,  the  array  of  counts  ( ’chnls'')  is  searched 

I 

i and  a list  made  of  the  number  of  ports  having  each  number  of 

I channels,  from  zero  to  nine  (’active").  This  array  is  then 
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printed  out. 

4.3.3  transmission  block  len9t^.  Each  tirre  a message  is  reject- 
ed because  of  buffer  overflow,  a 'b'  trace  message  is  output. 
Tnese  are  used  to  increment  an  array  ("bytes' ) whose  index  is  the 
naxJixjr  of  bytes  sent.  This  is  output  at  the  end,  giving  a dis- 
tribution of  the  number  of  tirrcs  each  num::x?r  of  bytes  was  sent. 
This  is  computed  only  for  the  CPU  outputs,  as  that  is  the  only 
place  'b'  messages  are  generated. 

4.3.4  organization.  The  arrangement  of  the  statistics 
program  follows  that  of  the  simulator.  The  main  routine  is  a 
while  loop  executed  each  time  an  'r'  message  is  found,  indicating 
the  start  of  a new  run.  'Ihe  routine  ’ getparams"  then  gets  and 
echoes  the  run  parameters  output  by  "initialize'  and  tne  routine 
"run"  reaas  the  trace  nessages  output  by  the  run"  routine  in  the 
sim,ulator  and  updates  the  data  structures  in  the  way  described 
above.  After  the  end  of  the  run,  tne  statistics  arc  output. 

"run"  uses  two  routines:  gettrace  ' reads  in  one  standard 
trace  ixessage  without  echoing  it  to  the  output.  This  is  where 
the  size  of  the  output  file  is  limited,  "getnum"  is  identical  to 
that  in  the  simulator,  except  that  it  does  not  echo  its  inputs; 
it  reads  a decimal  number  and  returns  its  value.  The  only  out- 
puts are  those  explicitly  produced  by  "getparams"  and  "run". 

The  statistics  program  must  thus  accept  the  inputs  from 
"initialize"  as  well  as  the  standard  trace  messages,  should  echo 
the  run  parameters  to  the  output,  and  must  be  able  to  take  into 
account  some  of  the  system  variables,  such  as  the  number  of  nodes 
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The  testing  of  the  simulator  has  two  aspects:  insuring 
that  it  is  operating  correctly  and  determining  how  well  it 
oiJerates.  This  must  also  be  done  when  nev/  modules  are  added  to 
the  program.  What  is  required  is  detailed  observation  of  runs 
and  measurement  of  execution  time  and  object  code  size. 

5.1  Correctors  of  C^ration 

Verifying  correct  operation  is  done  by  sending  messages  and 
checking  their  progress  and  interaction  at  each  tick.  This  is 
done  by  using  the  interactive  mode  and  by  adding  diagnostic 
prints  to  supolement  the  standard  trace  messages.  Testing 
proceeds  in  steps:  first  sending  a single  message  along  a speci- 
fied path,  then  sending  two  and  watching  their  collision,  and 
finally  using  a random  message  generator  and  checking  the 
results.  At  each  step  of  this  procedure,  all  the  possible  ac- 
tions should  be  explored,  that  is,  all  paths  through  the  simula- 
tor Should  be  exercised. 

5 . 2 Measurement 

The  efficiency  of  the  simulator  should  be  monitored  to 
determine  if  the  program  should  be  modified.  If  it  runs  too 
slowly,  unnecessary  code  can  be  removed.  For  example,  if  a 
series  of  simulations  uses  only  one  case  of  a particular  switch 
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j stateiTient,  the  switch  can  be  replaced  by  the  code  for  only  that 

case.  If  trace  outputs  are  generated  that  are  ignored  by  the 
statistics  routine,  those  output  statements  can  be  removed. 

Execution  time  should  also  be  studied  as  a function  of  net- 
work size  and  traffic  density.  Ihe  more  operations  occur,  the 
longer  the  simulation  will  require.  This  is  a result  of  the 
event  oriented  approach  the  simulator  uses. 

For  simulation  of  large  networks  requiring  iTiany  channels, 
the  object  file  may  require  more  .iiemory  than  is  available  on  the 
timesharing  system  under  which  the  simulator  was  created.  If  the 
code  cannot  be  compacted,  the  simulator  must  be  iTOved  to  another 
machine  and  possibly  implemented  in  a different  language  in  the 
process . 
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CGisCLUSlONS 


§•1  Measurements 

Measureii>ents  of  object  cocio  size  reveal  one  initial  advan- 
tage to  the  use  of  optimization  in  compiling  the  simulator.  Itie 
aiTount  of  executable  code  was  reduced  from  8602  bytes  to  7818,  a 
9%  reduction.  Unfortunately,  and  as  expected,  the  size  of  the 
data  structures  is  dominant.  For  a tree  of  128  nodes  with  six 
ports  (as  for  a full-ring  tree)  and  allowing  200  channels  and  100 
messages,  the  total  rremory  required  is  only  reduced  from  30,032 
bytes  to  29,249.  Ihe  Unix  operating  system  allows  the  user  only 
32,768  bytes;  this  could  be  exceeded  by  larger  trees  and  by  more 
active  trees  (which  would  require  more  simultaneously  active 
channels).  This  would  mean  that  parts  of  the  data  structure 
would  nave  to  be  stored  on  files,  greatly  increasing  the  run 
time,  or  the  simulator  would  have  to  be  transported  to  a dif- 
ferent host. 

6.2  Future  Directions 

6.2.1  Investigations.  A simulation  will  be  run  immediately  to 
compare  the  run  time  of  this  simulator  with  that  of  the  previous 
version  (not  implementing  virtual  channels) . The  results  will  be 
available  in  the  Unix  X-Tree  library  under  the  "simulator"  direc- 
tory where  the  program  is  kept.  Another  benchmarking  study  could 
compare  the  performance  of  the  simulator  with  and  without  optimi- 
zation; this  is  expected  to  be  the  main  advantage  of 


optimization. 


6.2.2  Simulator  development.  A nu.itier  of  imorovements  can  be 
made  to  the  simulator.  Allowing  multiple  or  more  complex  messaoe 
descriptors  at  each  nade  would  permit  transmitting  more  than  one 
block  of  bytes  down  a virtual  cnannel  while  measuring  transmis- 
sion times  for  each. 

Implementation  of  more  routing  algorithms  should  bo  the 
next  task  undertaken,  in  particular  a half-ring  or  fault-tolerant 
full-ring  algorithm.  The  latter  has  been  devised  by  Professor  C. 
H.  Sequin,  but  it  has  yet  to  be  implemented  on  the  sim.ulator. 
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Full-Ring  X-Tree 
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Figure  2 


X-Node  Organization 
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Figure  5a 
Physical  Channels 


Figure  5b 

Simulated  Channels 
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bit  = 1 implies 
alive 

CPU  sending 
controller  receiving 
CPU  rejected 

CPU  sending  channel  number 


visited  by  passl 

output  port  sending 

output  port  rejected 

output  port  sending  channel  number 

input  port  sending 

input  rejected 

CPU  sending 


Channel  Flag 
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- waiting  for  controller 

- sending  to  controller 

- sending  to  output  port 

- waiting  for  channel  at  output  port 


Figure  6 
Flag  Formats 
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_i  it-iiva’Ciic.N. 

The  X-Troe  dynamic  coiirminicationn  cin.ulator  is  a prorjram 
to  simulate  the  passing  of  messages  among  tno  nodes  in  a mul- 
tiprocessor computer  netv/ork.  v.hile  the  primary  application  is 
for  tne  hierarcnical  structures  considered  Cor  the  X-'Iree  system, 
the  simulator  can  bo  used  Cor  any  system  using  the  buffering  and 
protocols  described  in  the  I'eport. 

The  simulator  accepts  input  from  the  user  specifying 
para.meter  input  / data  output  lormiats,  workload  variables,  and 
system  variables.  Ine  simulator  produces  as  its  output  a trace 
of  all  activities  in  the  network  -which  may  Le  pioed  into  statis- 
tics routines  for  data  reduction  and  presentation. 

System  variables  include  network  structure,  message  rout- 
ing algorithm,  butter  size,  and  uisabled  links  and  nodes.  Work- 
load variables  determine  message  attributes  such  as  origin  and 
uestination,  generation  time  (or  frequency) , and  length. 

Currently-iniplemented  network  structures  include  simple 
binary,  full-ring,  and  naif-ring.  There  is  an  option  to  use  a 
binary  tree  with  extra  user -specified  links.  Messages  can  be 
generated  either  explicitly,  v/itu  origin,  destination,  and  start 
time  given  by  the  user,  or  ranaomdy,  with  length,  generation  fre- 
quency, and  transmission  distance  specified. 

The  remainder  of  this  guide  describes  the  the  operation 
of  the  simulator  from  the  user's  rxaint  of  view,  its  implementa- 
tion, and  procedures  for  modification. 

'Die  simulator  is  in  the  X-Tree  Unix  library,  at 
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/b/xtrco/liurnry/simulator 

lius  is  a directory  containing  an  explanatory  file  {'help'),  the 
simulator  ("XoIH  ) , tiic  simulator  source  (under  directory 
source"),  and  a copy  of  this  report  ('report'). 
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2 Sirr-'U^tor  Cjperation 


Tnis  section  describes  how  to  use  tne  simulator.  The 
Cirst  part  discusses  the  various  simulator,  system,  and  workload 
variables,  and  the  second  part  discusses  the  output. 

2.1  ^n  Defjnit^n 

Before  the  simulator  begins  execution  of  each  run,  it 
must  be  provided  with  information  aescribinq  tiie  system  and  work- 
load to  be  simulated  and  describing  the  parameter  input  and  trace 
output  formats  desired.  An  example  run  is  given  in  section  tnree 
of  tnis  guide. 

2.1.1  Input  formats.  For  user  familiarization  purposes,  tne 
simulator  can  accept  run  parameters  in  an  interactive  fashion, 
prompting  the  user  for  each  item.  Such  a run  is  illustrated  in 
Appendix  D.  For  longer  "production"  runs,  tlie  paraimeters  can  be 
supplied  from  a file  and  the  prompts  suppressed.  This  option  is 
selected  by  using  the  parameter  "-s"  when  the  simulator  is  exe- 
cuted. If  the  simulator's  executable  code  is  on  file  "XSIfl",  the 
shell  command  "XSIM"  will  cause  execution  in  the  interactive 
mode.  Tne  command  "XSIb  -s'  will  cause  execution  without 
prompts.  To  supply  parajTieters  from  file  ' PiM-AS-'S ' , the  command 
would  be 

"XSIM  -s  <FARAI1S" 
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2.1.2  CXjtuut  torinats.  As  mentioned  before,  tne  simulator  pro- 
duces a trace  of  all  activities  in  the  network.  For  interactive 
runs,  tnese  trace  messages  can  to  given  in  clear  english,  while 
for  runs  whose  data  is  piped  tnrough  a statistics  program  the 
messages  can  be  given  in  an  aboreviated,  easy-to-digest  form. 

This  selection  is  nade  with  the  first  parameter:  1 
selects  the  englisii  output  and  2 selects  the  appreviated  output. 
These  are  further  discussed  in  section  2.2. 

To  use  the  simulator  witti  a statistics  program  "STATS' 
and  store  the  data  on  the  lile  "CATA",  tlie  co.nmand  would  be 
"XSir.  -S  khAlAw'S  I STATS  >>LATA' 

Tne  double  right  arrow  will  catenate  tne  outout  data  onto  the  end 
of  the  data  file,  thus  allowing  results  of  several  runs  to  be  put 
onto  the  saTC  tile.  This  also  gives  a mechanism  to  record  tne 
execution  time  of  each  run,  by  using  the  I’nix  date  command, 
which  gives  the  date  and  tire.  Two  runs  with  parameters  on 
separate  files  could  be  placed  in  a snell  proerami: 
date  >>FATA 

XSin  -3  <PAFAM  I ST'A'i  >>TArA 
date  >>CA'iA 

X3IM  -S  <TAfA'i2  | STA'l  >>I  ATA 
date  >>CATA 

2.1.3  System  oefihitipn-  output  format  is  tne  first  paramKe- 

ter  input;  it  causes  outputs  to  be  eitner  Lnglish  messages  or 
abbreviated  messages  consisting  of  a character  and  three  integers 
(these  will  be  explained  below),  'i'he  next  group  of  parameters 
describe  the  system  being  simulated.  These  choose  the  buffer 
sizes,  number  of  nodes,  the  network  structure,  dead  links  and 
nodes. 
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Tlie  deougginj  level  can  t>3  set  to  one  to  cause  a dar.p  of 
^ tiie  state  of  the  nctvvork  after  each  pass  through  the  tree  to  find 

sending  no'des.  The  dump  shows  ;x) inters,  flags,  and  the  contents 
of  channels,  messages,  and  message  descriptors. 

The  input  and  output  buffer  sizes  can  each  be  set  in- 
< dependently  to  one  to  127  bytes. 

The  parameter  for  the  nurJoer  of  n'Odes  is  a positive  in- 
teger less  tnan  or  equal  to  127.  If  nore  ao-des  are  desired,  ttie 

source  code  must  be  modified  and  recompiled. 

There  are  four  choices  for  the  structure,  indicated  by 
the  integers  one  to  four,  ^ne  selects  tne  simple  binary  tree, 
wiiere  port  0 goes  to  the  parent,  1 to  the  left  child,  and  2 to 
the  right  chilu.  IWo  selects  tne  full-ring  tree,  wnere  ports  0 
to  2 are  as  before,  3 goes  to  tne  left  sibling,  and  4 to  the 
right  sibling.  Structure  three  selects  tne  half-ring  tree,  witn 
port  2 being  the  connection  to  sibling. 

Four  selects  a binary  tree  with  one  link  to  other  si- 
blings. Following  tlie  structure  para.meter,  tne  user  enters  one 

number  for  each  node,  indicating  the  no-Je  to  which  the  fourth 
port  is  attacneci.  If  two  conflicting  link  definitions  are  given, 
the  second  will  be  used. 

For  structure  four  the  user  must  supply  a routing  algo- 
rithm to  iTake  use  of  the  interconnections.  Ihis  involves  adding 
a case  to  the  switch  statement  in  the  RCUTF.  subroutine.  In  addi- 
tion, there  is  no  routing  algor itlmn  installea  for  structure  three 
(naif-ring).  Decause  of  this,  tne  initialization  routine  will 
not  accept  structures  three  and  tour. 

The  user  can  choose  to  disable  selected  links  or  nodes  in 
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the  structure,  Disabling  a noJe  or  link  is  done  by  entering  a 
line  oC  the  form: 

-1  2 3.1.2  4.3.1  5 

The  given  line  will  disable  nodes  1,  2,  and  5,  and  oorts  1 and  2 
of  node  3 and  ports  1 and  3 of  node  4.  The  nu.nbers  are  decimal 
aigits  — no  non-digits  except  appear  in  tne  commiand  string. 

The  final  system  variable  is  the  routing  algorithm.  One 
is  tiie  simple  binary  tree  algorithm,  two  is  the  simple  full-ring 
algor  ithiTi. 

2.1.4  Workload  definition.  The  workload  is  embodied  in  the  mes- 
sages sent  through  the  network.  The  user  can  define  message 
descriptors  to  generate  different  kinds  of  messages.  There  are 
four  types  of  descriptors  currently  implemented:  specified  mes- 
sages, random  messages  to  non-leaves,  leaf-to-leaf  messages  with 
flat  distribution,  and  leaf-to-lcaf  with  normal  distribution. 

For  each  descriptor  of  any  type,  tlie  user  specifies  the 
address  and  total  length,  in  bytes.  For  type  one  (specified) 
descriptors,  tne  start  time  and  destination  node  are  also  speci- 
fied. For  tyf.es  two,  three,  and  four,  the  frequency  of  genera- 
tion is  specified  as  the  ratio  of  two  integers.  For  type  two 
descriptors,  the  destination  is  cnosen  at  random  from  the  non- 
leaves; for  type  three,  fro;;i  tne  leaves,  witn  each  leaf  having 
equal  probability.  For  type  four  descriptors,  a standard  devia- 
tion is  also  given,  with  its  units  representing  the  horizontal 
distance  in  nodes  from  the  sender.  This  descriptor  thereby  sends 
from  leaf-to-loaf  with  the  nearer  leaves  selected  more  often  to 
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simulate  conwunication  locality.  Finally,  the  kind  of  tne  mes- 
sage is  set  to  either  teardown  or  non-tearoown. 

Several  different  descriptors  of  each  type  can  be  defined, 
each  having  a different  set  of  nodes  using  it.  For  example,  some 
leaves  can  generate  messages  to  other  leaves  with  one  standard 
deviation  and  other  leaves  can  have  another.  If  a node  is  as- 
signed no  descriptor,  it  will  aenorate  no  messages. 

Ihe  user  may  add  his  own  workload-producing  routine,  but 
this  will  require  modification  of  the  initialization  and  genera- 
tion routines. 

2.1.5  pth_er  paranieters.  After  specifying  tne  workload,  the  user 
must  give  the  length  of  the  run  in  ticks.  This  is  a positive 
integer. 

After  the  run  is  finished,  tne  simulator  reads  the  input 
to  determine  whether  to  start  on  another  run.  The  letter  "y 
will  cause  tiie  sim.ulator  to  reinitialize  anu  execute,  any  other 
will  cause  program  termination.  Obviously,  if  another  run  is 
started,  the  parameter  file  must  contain  another  set  of  .parame- 
ters. 

2.1.6  parameter  retention.  r,o5t  parameters  are  kept  the  sa.me 
from  run  to  run.  Ey  entering  a zero  or  a return  the  old  parame- 
ter will  be  used.  Tne  two  exceptions  are  tor  dead  links  and  mes- 
sage descriptors;  both  of  these  are  cleared  and  must  be  re- 
entered with  each  run. 

2.2  Trace  Output 
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'ine  si.T.ulator  produces  a series  of  messages  describing 
the  progress  of  the  simulation.  For  output  format  one  (englisn) 
tne  messages  are  self-explanatory.  F'or  forirat  two  (abbreviated) , 
tney  are  of  tlie  torin  <letter>  <integerl>  <integer2>  <integer2>. 

Five  of  the  twelve  rressages  proviae  information  about  the 
simulator.  By  letter,  tney  are: 

r:  Start  of  a new  run.  The  tnree  integers  are  zero. 

The  following  integers  are  the  run  parameters  being  echoed. 

t:  Start  of  a new  tick.  <integerl>  is  the  tick  numiDer, 

and  tne  other  two  fields  are  zero. 

n:  Ko  more  items  from,  a free  list.  'Ihis  indicates  that 

eitner  messages,  descriptors,  or  channels  are  being  used  faster 
than  they  are  being  released  and  tne  appropriate  free  list  has 
run  dry.  <integerl>  is  tiie  node  namber,  <inteqer2>  is  tiie  (X)rt, 
and  < integer 3>  is  0 for  rressages,  1 for  channels,  or  2 for 
descriptors. 

e:  Sno  of  run.  Other  fields  are  zero.  The  next  charac- 
ter will  be  the  echo  of  the  continuation  ('y  or  'n'). 

x:  Lno  of  session,  otrier  fields  are  zero.  'Ihis  is  tne 

last  iTiossage. 

The  otner  eight  messaaes  describe  tne  progress  of  mes- 
sages through  the  system. These  are: 

a:  ^essage  has  arrived  at  its  destination.  (Last  byte 

sent  to  the  CPU.)  <integerl>  is  tne  destination  node,  <integer2> 
is  the  path  length,  and  <integ3rJ>  is  the  start  time. 

b:  Transmission  has  been  interrupted  after  a string  of 
several  consecutive  bytes.  <integerl>  is  tne  sending  node, 


Insse 
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<integ3r2>  ti)o  oort,  and  <intcgcr3>  tne  nardcr  of  bytes, 
messages  are  currently  only  generated  tor  the  CPU  output. 

f:  Buffer  full  — a byte  was  rejected  because  the  re- 
ceiving buffer  was  full.  < integer 1>  is  the  sending  node,  < in- 
teger 2>  the  output  port,  and  <integer3>  is  U if  an  input  port,  1 
if  an  output  port,  2 if  an  input  sending  to  the  controller,  and  3 
if  an  output  from  the  CPU. 

g;  Get  new  cnannel  — a new  cnannel  has  been  selected 
for  transmission.  This  messaae  is  suppressed  for  input  ports 
wnen  a new  channel  is  selected  after  every  byte  is  sent.  <in- 
tegerl>  is  the  node,  <inteqer2>  is  the  port>,  and  <integer3>  is  U 
for  an  input  port  and  1 tor  a output  port. 

1:  Goth  nodes  on  a link  could  send  and  only  one  did. 
<integerl>  is  a node,  <integer2>  is  its  port,  and  <integer3>  is  U 
if  tnat  node  sent,  2 if  ttie  otner  sent, 

cj:  i'\n  adoress  was  received,  tne  message  routed,  and  a 
channel  created  at  the  selected  output  port.  <integorl>  is  the 
node,  <integer2>  tne  input  port,  and  <intoger3>  is  the  number  of 
channels  at  the  input  port. 

s:  Cne  byte  sent  at  a port.  <inteqerl>  is  the  node, 
<integer2>  is  the  pxirt,  and  <integer3>  is  0 for  an  input  port 
sending  to  an  outout,  1 tor  an  output  sending  across  a link,  2 
for  the  CPU  output,  and  3 for  an  input  sending  to  the  controller. 
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3 LXAT’ilr'LL  liViLl'ACl  IVb'  KUi'i 


Bracketed  statenents  are  cOiTOientc:. 


What  output  forinat: 

1:  English 
2:  Aboreviated 
Currently  1:1 
i.nat  debugging  level: 

1 : none 

2:  duTD  alter  passl 
Currently  1 :1 

V.hat  size  inout  buffer?  (0):4 
Vihat  size  output  buffer?  (L’):4 

Coes  input  port  send  more  tnan  one  consecutive  byte  per  channel? 
1:  No 
2 : Yes 

Currently:  1 :2 
how  many  nodes  in  tree?  (U):3 
v.hat  tree  structure: 

1:  Simole  binary 
2:  Null-ring 
3:  Half-ring* 

4:  Binary  witn  one  uscr-defineu  link* 

*:  No  routing  algorithms 
Currently  1:1 
Kill  nodes  and  links 

to  kill,  return  to  exit 
bpecify  as  ’-n  n n.p  n.p.p',  etc. 

(return  entered  to  exit] 

v.hat  routing  algorithm? 

1:  Siniole  binary 
2:  Full-ring 
Currently  1:  1 

Set  up  message  uescriptors  ana  assign  nodes  to  them 
Enter  descriptor  type: 

1:  Specified 

2:  Random  to  non-leaf 

3:  Leaf-to-leaf  with  flat  r.iistr ibution 

4:  Leaf-to-leaf  with  ncrmial  distribution 

Enter  return  to  quit 

1 

Enter  address  lengtli  and  total  length: 

1 4 

Enter  start  time  and  destination: 

1 2 

Is  tliis  a tearoown  (E  = no,  1 = yes)  :0 
Enter  nodes  to  use  this  descriptor 

1 

Enter  descriptor  type: 

1:  Specified 

A-IU 


2:  Candor.',  to  non-leaf 

3:  Leaf-to-lea£  witti  flat  distribution 

4:  Lea£-to-leaf  with  norinai  distribution 

Lnter  return  to  quit  (return  entered  to  exit) 

.%hat  length  ot  run  in  ticks?  (U):15 

Start  of  run  at  node  lUC,  j-ort  4:  ij  Inooe  and  port  meaningless] 
time  is  1 [message  generated] 

time  is  2 

Start  new  channel  at  node  1,  port  3:  U [only  channel  number  sent] 
time  is  3 

Start  new  channel  at  node  1,  part  3:  0 

one  byte  sent  at  node  1,  port  3:  2 ||il  from  CE^U  to  port  3 input] 

time  IS  4 

One  byte  sent  at  node  1,  port  3:  3 lao  iress  byte  to  controller] 

Cnannel  created  at  node  1,  port  3:  0 at  output  rxart  to  node  2] 

One  byte  sent  at  node  1,  ix)rt  3:  2 #2  from  Ci^  to  input] 

time  IS  5 

Start  new  channel  at  node  1,  port  1:  0 
Start  new  channel  at  node  1,  port  1:  1 

One  byte  se.- t at  node  1/  port  3:  C [jfl  from  input  from  Ct'U  to  output] 

One  byte  sent  at  node  1,  part  3:  2 it 3 from  CFuj 

tiiTx;  IS  6 

Start  new  channel  at  no-Je  1,  port  1:  fl 

One  byte  sent  at  node  1,  p^art  3:  1)  j:2  from  CFU  input  to  output] 

One  byte  sent  at  node  1,  oort  3:  2 i:4  from  CE^J 

channel  numoer  across  link] 

time  is  7 

Start  new  channel  at  node  1,  port  1:  0 

Start  new  channel  at  node  1.  part  3:  1 

One  byte  sent  at  node  1,  part  1:  1 [ill  across  link] 

One  byte  sent  at  novde  1,  oort  3:  i!  |?3  from  CPU  input] 

time  IS  8 

Start  new  channel  at  node  1,  port  3;  1 

one  layte  sent  at  nooe  1,  port' 1:  1 fl2  across  link] 

One  byte  sent  at  node  1,  ixart  3:  0 i:4  from  CPU  input] 

One  byte  sent  at  node  2,  port  !’:  3 address  byte  to  node  2 controller] 

Channel  created  at  node  2,  port  i):  U [to  node  2 CPU] 
time  is  9 

Start  new  channel  at  node  1,  part  3:  0 

Start  new  channel  at  no-ae  1/  port  3:  1 

Start  new  channel  at  node  2,  part  3:  1 

One  byte  sent  at  node  1,  port  1:  1 [#3  across  link] 

One  byte  sent  at  node  2,  port  0:  n [fl  from  input  from  link] 

time  IS  10 

Start  new  channel  at  node  1,  part  3:  0 

Start  new  channel  at  node  1,  port  3:  1 

One  byte  sent  at  no'je  1,  port  1:  1 [ii3  across  link] 

One  byte  sent  at  node  2,  port  0:  o [((2  from  input  from  link] 

time  13  11 

Start  new  channel  at  node  1,  port  1;  1 

Start  now  channel  at  node  1,  port  3;  0 

Start  new  channel  at  node  1,  port  3:  1 

One  byte  sent  at  node  2,  port  0:  E)  [O  from  input  from  link] 

One  byte  sent  at  node  2,  part  3:  1 (#1  to  CPU] 

time  IS  12 

Start  new  channel  at  node  1,  port  1;  1 
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start  now  channel  at  noae  1,  wrt  3:  U 

Start  new  channel  at  node  1,  rwrt  3:  1 

cne  byte  sent  at  node  2,  pert  h:  U 
Cne  byte  sent  at  node  2,  pi.>rt  3:  1 
tiire  IS  13 

Start  new  channel  at  node  1,  port  1;  il 

Start  new  channel  at  node  1,  port  1:  1 

Start  new  channel  at  node  1,  jxjrt  3:  0 

Start  new  channel  at  node  1,  part  3:  1 

Une  byte  sent  at  node  2,  port  3:  1 
time  IS  14 

Start  new  channel  at  node  1,  port  1:  P 

Start  now  channel  at  node  1,  port  1:  1 

Start  new  channel  at  no-Je  1,  port  3:  h 

Start  new  channel  at  noao  1.  part  3;  1 

Cne  byte  sent  at  node  2,  rxart  3:  1 
i'essa^e  arrives  at  2 £rom‘  1 since  1 
ti.Tc  IS  15 

Start  new  channel  at  noae  1,  port  1:  0 

Start  new  cnannel  at  node  1,  [urt  1:  1 

start  new  channel  at  no-de  1,  (wrt  3;  (1 

Start  new  channel  at  node  1,  uort  3:  1 

Start  new  channel  at  n(xio  2,  bort  3:  1 

Lno  of  run  at  node  4,  port  4:'i! 

Lo  you  wish  to  continue  (y-n)?;n 
Lnd  of  session  at  noue  4,  rort  4:  0 


“4  fro.n  input  fro.T.  link] 
S2  to  CPU) 


lO  to  CPU] 


(M  to  CPU] 

[searen  in  vain  for  channel 
witti  data) 

(no'.ie  and  port  meaningless] 
(nooe  and  port  meaningless] 
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In  tile  "printf  5tatGir,ents  in  tni 
routine  in  Aooendix  C,  the 
orintcd  as  a pound  sign 

/*  X-Tree  Lynanic  Comn-iunications 


s proqra.n  and 
backslash-n  , 


Siirulator 


in  the  statistics 
or  end-of-line,  is 


Paul  A.  Suhler 
14  Kay  197e 


Constant  Declarations  */ 


UdeCine  ;',GCLJ''AX  128 
ji define  PGRiKAX  G 
“:de£ine  CliGLKAX  2o8 
ioefine  K.SGKAX  100 
li define  CDSCMAX  5 


/*  nodes  in  tree  */ 

/*rort5  nor  node,  incl.  cou  */ 
/*'chnls  in  syster  */ 

/*  messa'-ies  in  syste.T  */ 

/*  different  niessaae  descriptors  */ 


/*  Type  Declarations  */ 


struct  msdstype  {struct  nedstyne  *nextd; 

cnar  dkini,  ale;vg,  mkind;  int  mlena,  il,  i2; 
float  fre*.!; 

struct  msgtyoe  jstruct  msgtype  *nextm;  int  source,  dest,  stinie,  lenqth; 
char  kir.i,  aaleng; 

struct  chnltype  jstruct  chnltyse  *nextc,  *lastc,  *de3tc; 

struct  trsgtypd  *Cir,sg;  char  outbuf,  inbuf,  cflag; 


struct  porttype 


struct  nodetype 


{struct  chnltype 
struct  noJety-e 
struct  Dorttv-e 
int  chnls;  char 

jstruct  porttype 
struct  chnlty.oe 
struct  desctyiae 
int  cpbytcs; 


*inchnl,  *outchnl; 

*ornode;  struct  msqtype  *qnead,  *qtail; 

*link; 

pflag; 

oor 1 1 pop'll' AX  1 ; char  nflag,  cpchnls,  conbuf; 
*cooutchnl,  *waithead,  *waittail; 

♦rrisgdesc ; 


/*  Variable  Declarations  */ 

struct  msdstype  descr  iptor  |DL5;C'!AX1  , *freGde5c; 
struct  chnltype  chnl  [uii'iLlVsX] , *freechnl; 
struct  msg type  message  [I 'SGMA.X]  , *freemsg; 
struct  noaetype  node [NODEMAX] ; 

int  nodenum,  portnum,  chnlnuri,  inbuflim,  outbuflim; 
char  shape,  rtalgo,  pronipt,  output,  c,  getnew,  debug; 

int  n,  p,  tick,  timelim; 
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r include  's4h" 

/*  mm:;  — Upon  initial  entry,  the  pro.'T^nt  ootion  is  cleared  i£  tne 
simulator  was  called  with  a -s  argurreht.  'inen,  each  tinie  a 
simulaton  is  run,  tne  si.Tulator  is  initialized  and  the  run  is  made. 
After  tne  run,  tne  simulator  terminates  if  a 'y'  is  not  read  in.  V 

main  (argc,argv) 

int  argc;  char  **argv; 

(cnar  c; 

prompt  =!  ((argc  > 1)  &&  (argv(l][l]  ==  's')); 
a, Id:  initialize () ; 

runO; 

if  (proapt)  printf  ("if  i-to  you  wish  to  continue  (y-n)?:'); 
c = putcnar  (qetcnar  0 j ; getcharO; 
it  (c  ==  'y')  goto  mlp; 
else 

I,  = 


/*  I'Ui'i  — run  clears  certain  -xiinters  and  flans,  sets  uo  free  lists 
of  iiiessages  and  channels,  and'  then  runs  the  simulation  according  to  tne 
paraa-etefs  read  in  in  "initialize'.  For  tne  first  pass,  '’oassl  is  called 
if  tne  nooe  is  alive  and  tne  port  has  a li've  link  and  is  uhvisited. 

After  each  nooe  is  processed,  ' aenerate ' is  called  if  tnere  is  a message 
oescriotor  at  tnat  node.  For  the  second  pass,  if  the  node  is  alive  ana 
the  port  is  marked  as  sending  pass 2'  is  called.  */ 

run() 

( reqister  struct  portty'oc  *tDort; 
reqistcr  struct  nodetyhe  *thode; 

/*' clear  nodes  and  ports  */ 

for  (n=l;  n<=nodenum;  n-H-) 

{ tnooe  = « (node In) ) ; 

tnodc->cpchnls  = tnode->conbut  = tnoje->CDbytes  = 0: 
tnodG->cooutchnl  = tnodo->v.aithead  = tnooe->waittail  = 0; 
for  (p=0';  p<=Dortnu.Ti;  p4  + ) 

{ tport  = Mthode->port  loj ) ; 
tport->inchnl  = tport->outchnl  = tpxirt->qhead  = 0; 
tport->chnls  = tport->ptlag  = 0; 
tport->prnoae  = cnode; 


/*  set  up  lists  of  free  messages  and  chnls  */ 

for  (n=0:  tKCildLFAX;  n++) 

chnl (nj .nextc  = & (chnl ln+1] ) ; 
chnl  (Chdu-iAX  - 11. nextc  = 0; 
freechnl  = & (chnl (B) ) ; 

for  (n=U;  n<MSC:'AX;  n++) 
nessage  [n]  .nextm  = & (mes-sage  (n+l) ) ; 
nessage (MbCriAX  - IJ.nextm  = h; 
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free.Tisg  = S.  (message  (0) ) ; 

/*  run  simulation  */ 
printmsgCr ' ,C) ; 

Cor  (tick=l:  tick<=timclim;  tick++) 

{ printmsg ( t' , tick); 
lor  (n=l;  n<=no<Jenum;  n+4) 

if  ((tnode  = & (nooe In] ) ) ->nflaq  & 00J1) 

( /*  noue  is  alive  v 
for  (p=0;  p<=Dortnu.Ti;  p++) 

( if  ((((twrt  = s (tno:ie->portlp) ) )->pflag  & 1)  ==  0)  &£< 
(tport->link) ) 

/*  port  unvisifced  this  tick  and  link  alive  */ 

^ passl (tport) ; 

if  (tnoc]e->;Tsgde3c) 

^ generate (tport,  fcnude-Xmsgdesc) ; 

if  (debuu  ==  2) 
dump  ( ) ; 

for  (n=l;  n<=no-jenum;  n++) 

it  ((tnode  = & (none  [n] )) ->nClag  & 0?.-'l) 

/*  if  node  is  alive,  process  */ 
for  (p=0;  p<=portnuit;  tj-H-) 

{ if  ( (tport  = & (tnojs->port  (pj ) ) ->pf  lag  s,  C122) 

/*  inout,  output,  or  epu  port  sending  */ 
pass 2'( tport) 

tport->pflag  =&  037C;  /*  r.ark  unvisited  */ 

if  (c^ebug  ==  2) 

^ damp  ( ) ; 

printmsg  ( 'e ' ,(’) ; 

/*  run  V 
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^include  ■s4h" 

/*  INITIALIZE  V 

initializeO 

( register  int  num; 
int  IT.; 

register  struct  msdstype  *f>desc; 
register  struct  uortty^  *pp; 

/*  get  output  forirat  */ 
if  (outout  ==  0) 
output  = 1; 
if  (pro.Tot) 

{ or intf ■( 'Vihat  output  fonrat:i:  ); 
printff"  1:  Englishl  ) ; 

urintfi''  2:  AbbreviateJS  ); 

^ printf(’  Currently  %d:" , output) ; 

output  = ((nuTi  = getnum 0)  ? num  ; outout); 
printf(''?d#  .output); 

/*  get  debugging  level  */ 

if  (debug  ==  0) 

(clebug  = 1)  ; 
if  (prompt) 

{ pr  intf  ('tshat  uebugging  level:)!  ); 
orintfi"  1:  none)!  ); 

printff"  2:  damp  after  passl))  ) ; 

printf("  Currently  %d  ,dci)ug); 

iebuq  = {(num  = qetnumO)  ? num  : debug); 
prin£f("%u#  , debug); 

/*  get  input  buffer  limit  */ 

ibuflo: 

if  (prompt) 

pr intf'C'^'hat  size  incut  buffer?  (?,d)  : ' , inbuflim)  ; 
if  (((num  = getnamO)  < 0)  ||  (nam  > 127)) 

{ printfC’  wrong  — must  be  in  range  1 to  127  bytes.  Try  again.  )!  ); 
goto  ibuflo; 

else 

inbuflim  = (num  ? num  : inLuflim); 
pr intf  ("%d))  , inbuflim) ; 

/*  get  output  buffer  limit  */ 

obuf Ip: 

if  (prompt) 

printfC'lvhat  size  outout  buffer?  (?,d):  ,outbuflim); 
if  ( ( (num  = getnumO)  < R)  ||  (num  > 127)) 

{ printfC  Wrong  — must  be  in  range  1 to  127.  Try  again.  C); 
goto  obuf Id; 
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else 

outbuflim  = (nu.p  ? nur:,  : outbuflim); 
printfC'ld#'  ,outbu£iim) ; 

if  (getnew  ==  u) 
getnew  = 1; 
if  (pro.T.Dt) 

{ printf("  Cogs  inout  oort  send  nnore  tnan  one  consecutive  byte  oer); 

^ printer’  channel;”#  ' 1:  .’/oii  2:  Yes#  Currently:  %a  :'',gGtnew); 

getnew  = {(nu.Ti  = getnumO)  ? nun  : getnew); 
printf ("laF  .getnew) ; 

/*  get  number  of  nodes  in  tree  */ 

nnanlo: 

if  (promot) 

printfC'How  many  nodes  in  tree?  (%d) .no'-ienun) ; 
if  ( (num  = qetnuinO)  >=  NUCrI'AX) 

{ printff”  Sorry,  maximum  of  ?J  nodes  allowed.  # .tJODLMAX  - 1); 
print£(''  to  get  more,  modify  source  ani  recompile.  #'  ) ; 
goto  nnumdp; 

else 

nodenuii  = (num  ? num  ; ncxienum) ; 
printf  C'id#" , nodenum) ; 

/*  get  structure  */ 


if  (shape  == 
shape  = 1; 
shaplo: 

it  (prompt) 


{ printf 
br intf 
printf 
printf 
printf 
printf 
printf 


l\hat  tree  structure;#  ) ; 

1:  Simole  binary#  ) ; 

2:  Full-ring#  ); 

3:  llalf-rinj*#' ) ; 

4:  Binary  with  one  user-defined  link*#"); 
*:  No  routine  alaorithms#  ); 

Currently  t-d: shape) ; 


[ (c  = getnum ( ) ) 
if  ((c  >=  1)  && 
shape  = c; 
else 


(c  <= 


{ printf ('  Invalid  selection;  try  again;#'); 
goto  snaplp; 


printf  (”%d#  ' .sha^^) ; 

/*  set  portnum  */ 
switch (shape) 

{ case  1:  portnum  = 3;  break; 
case  2:  portnum  = 5;  break; 
case  3:  case  4;  portnum  = 4;  break; 


/*  initialize  entire  structure  */ 
tor  (n=l;  n<=nO'Jenu:Ti;  n++) 


{ tor  (p=0;  p<portnum;  p++) 

{ if((pp  = &'{node  (n)  .^rt  (p) ) ) ->link  = otherportO) 
^ pp->link->link  = pp; 

node  Ini  .port  [portnuTi] . link  = 1; 
node  n .iVsqdesc  = 0; 
no-de  n]  .nflag  = 1; 


/*  kill  nodes  and  ports  */ 
it  (proiT-.pt) 

{ Drintf("kill  noaes  and  linksii'); 

printtc"  to  kill,  return  to  exitii  ); 

^ printti"  Specity  as  '-n  n n.o  n.p.p’,  etc.ijjt  ); 

while  ( (c  = cutc'nar  (getchar  0 ) ) == 
wnile  (c  !=  '#') 

{ n = getnumO  ; 
printf  C'^d^c'  ,n,c) ; 


it  {(n  >=  1)  &S,  (n  <=  nodenar,)) 

{ if  ((c  ==  ' ')  II  (c  ==  •#'j) 

{ nooe (nj .ntlag  =&  G3/6; 
for  (p=0;  D<oortnuii;  [:++) 
if  (op  =' olnerport 0 ) 
pp->link  = 0; 

} 

else 

while  (c  ==  ' . ' ) 

{ p = gstnumO  ; 
printf ( td%c ' ,P,c) ; 
if  ( (u  >=  0)  &&  (p  <=  ixirtnar,)) 
{ p[i.=  & (no^jelnl  .rortlp] ) ; 

1 if  (oo->link  > 1) 

pp->link->iink  = O; 
pp->iink  = 0; 


printf  {'  Port  nurter  %d  invalids"  ,p)  ; 


printf  ("Node  number  ?.d  invalid# '.n); 


/*  Select  routing  algorithm  */ 

it  (rtalgo  ==  S) 
rtalgo  = 1; 


i 


rtlD: 

i£  (proiTrpt) 

{ printf  ("i.hat  routine  algor  ith.Ti?#  ); 
print£i"  1:  Simole  binary*  ); 

printfi"  2:  Full-ring*  ); 

printf ("  Currently  %u:  '^.rtalgo); 

if  {({nun  = getnunO)  >=  fi)  II  (nu;Ti  <=  2)) 
rtalgo  = (nan  ? num  : rtalgo); 
else 

{ printf  (■'  Invalid  selection;  try  aaain*  ); 
goto  rtlp; 

printf ("?d#,  rtalgo); 

/*  set  up  iTiessage  descriptors  */ 

for  (n=0;  n<CL3Ci.AX-l;  n++) 
descriptor  In] .nextd  = &(ue3criptor(n+lJ); 
descriptor (CtGCrv\X-l] .nextd  = 0; 

Ireedesc  = & (descriptor [FJ ) ; 

it  (oronpt) 

orintf("Set  uo  iressage  descriptors  and  assign  nodes  to  then*'); 
while  (n) 

{ if  (prompt) 


{ printf 
printf 
printf 
orintf 
printf 
printf 


Lnter  descriptor  type:*'); 

1:  Soecifiecdi  ); 

2:  Fandom  to  non-leaf*  ); 

3:  Ijeaf-to-leaf  with  fiat  distribution*'); 

4:  Leaf-to-iea£  with  normal  distribution*  ) ; 
Enter  return  to  quit*  ) ; 


if  (lln  = getnuml))  >=  1)  &S,  (n  <=  4)) 

{ printf ( id*  , n) ; 
if  (pdesc  = freedesc) 

{ freedesc  = pdesc->nextd; 
pdesc->Jkind  = n; 
if  (pro.ipt) 

printf  ("  Lnter  address  lemith  and  total  length:*  ); 
pdesc->aleng  =getnu.;,n;  printf  ( Id  ’ ,od3Sc->alenq)  ; 
pdesc->i;J.eng  = gotnu:ii();  printf  (' ?:d*  ' ,^esc->mleng) ; 
switch (n) 

{ case  1:  /*  specified  */ 

if  (prbmrjt) 


case  4: 


case  2: 
case  3: 


pdosc->i2  = getnumO;  printf  ("td*"  ,pdesc->i2)  ; 
break; 

/*  normal  leaf-leaf  */ 
if  (proiTiot) 

printf F'  Lnter  standard  deviation:*  ); 
pdesc->il  =getnuiTi();  printf  ('%d*  ' ,pdesc->il) ; 

/*  oage  */ 

/*  leaf-leaf,  flat  */ 
if  (prompt) 


) 


print£(  Lnter  Ireauency  as  'j/k':  ); 
num  = qetnuT.  0 ; 
pdesc->freq  = num; 
printC(  IJ/  ,nuri); 
if  (m  = getnuinO  ) 

pae5C->£req  =/  m;  printf('?d#' ,m) ; 
break; 

/*  switch  */ 


} 


if  (prOiXpt) 

printf  ( ' Is  tnis  a teardown  (0  = no,  1 = yes):  ); 
pdesc->mkind  = getnu:ii(); 
printf  (‘'%d#‘'  ,pdesc->mkind) ; 

if  (pro.TiDt) 

printf'C  Enter  nodes  to  use  this  descriptor#'); 

C “ * 3 ' * 

while  (c  !=  '#') 

{ if  ( ( (nuTi  = getnu!Ti())  >=  1)  &&  (nuTi  <=  node  lum) ) 

( node (num)  .msgdesc  = pdesc;  printf  ("?,d  ".nmi);  } 
else 

printf  (■'  Invalid  node  number  :?d#’‘ , nun)  ; 
printf  (■■'#"); 


} 


else 

^ printmsg ( 'n' , 2) ; 

else 
if  (n) 

orintf("  Invalid  selection;  try  again.  #‘ ) ; 


/*  get  length  of  run  V 
if  (prompt) 

pr intf ("i.hat  length  of  run  in  ticks?  (?d):',  timelim) ; 
if  (num  = getnumOI 

timelim  = (num  ? num  ; timelim); 
printf  ("?d#'  , timelim) ; 

/*  initialize  */ 


"include  "s4h  ' 


/*  F/VISI  — pass  one  is  called  by  run  for  tnose  ;jorts  with  non-zero 
links  (not  already  visited)  in  alive  nodes.  Pass  one  narks  those  ports 
having  channels  witn  data  to  send.  Ihis  is  done  for  the  inout  and  output 
at  both  the  current  port  and  for  the  inout  and  output  at  the  rxjrt  indicated 
by  link  . 

for  input  oorts,  the  senaing  flag  is  set  immediately  if  there  is 
m,ore  data  in  ' inbul  ' , if  there  was  no  reject,  and  if  ’getnew'  is  set  to  2. 
any  of  tnese  fails,  findinchnl  is  used  to  search  for  t.ne  next  channel  with 
data;  if  found,  the  inchnl''  pointer  is  reset  and  the  sending  flag  is  sot. 

If  tnere  are  no  channels  with  data,  the  sendina  flag  is  cleared. 

For  output  ports,  a similar  procedure  is  followed,  exceot  that  when 
a new  channel  is  selected,  tne  senaing  channel  nunber  flag  is  also  sat.  Ttie 
output  to  CPU  is  processed  in  a separate  section  of  code  because  the  CPU's 
representation  is  actually  a part  of  the  current  node.  Defore  the  outtxit 
sending  flags  are  set,  that  in  the  current  ;.x)rt  is  saved.  It  both  [>orts 
want  to  sena,  the  contention  can  then  be  resolved  in  favor  of  the  oort 
that  did  not  send  in  the  last  tick. 

V 

passl (port) 

register  struct  px>rttype  *port; 

{ register  struct  chnltype  *chnl; 
struct  chnltyix?  *nchnl; 
register  struct  porttype  *oport; 
struct  nodetype  *pnoas; 
char  flag; 

/*  Inis  input  port  */ 

if  (chnl  = :x)rt->inchnl) 

{ /*  tnere  is  an  active  channel  */ 
if  ((getnew  ==  2)  &&  (cnnl->inbuf ) &&  ( (Port->pf  lag  & 0y4ti)  ==  C) ) 

/*  irore  data  and  not  rejected  */ 
port->Ptlag  =|  CB20: 

else  ' /*  eittier  current  channel  rejected  or  no  data  — find  new  */ 
( if  (nchnl  = f Indinchnl  (cnnl) ) 

{ /*  ttiere  is  a channel  witn  data  */ 
uort->incnnl  = ncnnl; 

^ port->pIlaj  =1  0i;2O; 

else  /*  no  channels  with  data  */ 

^ port->pflag  =&  0357; 

^ port->pflag  =&  0337;  /*  clear  reject  */ 

else  /*  no  active  channels  — mark  'not  sending'  */ 

port->pflag  =&  0357; 

/*  Other  input  oort  */ 

if  (p  < portnum)  /*  check  not  CPU  — no  other  port  */ 

{ if  (chnl  = (ofxirt  = Port->l ink) -> inchnl) 

{ /*  link  is  there  and  there  is  an  active  channel  */ 
if  ((getnew  ==  2)  &&  (chnl->inbuf ) Uh  ( (cport->pflag  & B()4C)  ==  0)) 
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If 


/*  more  data  and  not  rejected  */ 
ooort->p£laa  =|  C'j2Jj 

else  either  current  channel  rejected  or  no  data  — fino  new  */ 

( if  (ncnnl  = f indinchnl  (chnl) ) 

( /*  there  is  a channel  with  data  */ 
opor t->inchnl  = nchnl; 

^ oport->pflag  =|  0320; 

else  /*  no  channels  witri  data  */ 
oport->p£lag  =&  0357; 

^ oport->pflag  =&  0337;  /*  clear  reject  */ 

else  /*  no  active  channels  — mark  'not  sending'  */ 

oport->p£log  =&  0357; 


/*  determine  if  this  output  port  wants  to  send  */ 

flag  = port->p£lag  & C0tj2;  /*  save  whetner  it  was  sending  */ 
if  (chnl  = [xirt-'^outchnl) 

( /*  if  any  active  channels  */ 
if  ( (chnl->outbu£)  ( (port->p£lag  S.  0004)  ==  0)) 

/*  data  in  current  channel  and  not  rejected  */ 
port->pflag  =|  0002; 
else 

{ if  (nchnl  = findoutchnl  (chnl) ) 

{ /*  there  is  a channel  with  data  */ 
port->outchnl  = nchnl; 

^rt->Dflag  =|  0012;  /*  sending  channel  number  */ 

else  /*  no  channels  with  data  */ 

^ port->pflug  =&  0375; 

^ port->pflag  =&  0373;  /*  clear  reject  */ 

else  /*  no  channels  — not  sending  */ 

port->pflag  =&  0375; 

/*  determine  if  other  port  on  link  wants  to  send  and  then  resolve 

contention  for  link,  done  separately  for  epu  and  non-cpu  links  */ 

if  (p  < ;x)rtnum) 

{ /*  link  to  otner  node  */ 
if  (cnnl  = (oport  = port->iink)->outciinl) 

{ /*  active  channel  there  */ 
if  ( (chnl->outbuf ) &&  { (opor t->Df lag  s 0004)  ==  0)) 

/*  current  channel  has  aata  and  was  not  rejected  */ 

0(X)rt->Dflag  =|  0002; 
else 

{ if  (nchnl  = findoutchnl (chnl) ) 

{ /*  channel  exists  witti  data  */ 
oport->outchnl  = nchnl; 

^ oport->pflag  =|  0012; 

else  /*  no  channel  with  data  */ 
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oport->pflag  =s  0375; 

oport->o£laa  =&  0373;  /*  clear  reject  */ 

else  /*  no  channels  */ 

oport->p£lag  =&  0375; 

/*  i£  both  v.ant  to  send,  give  link  to  one  that  didn't  send  last  */ 

i£  ( (port->o£lag  & C0C2)  (ooor t->r;£laq  s 0002)) 

{ if  (flaa) 

IX)rt-^pflag  =&  0375; 
else 


ocort->p£lag  =&  0375; 
prihtni5g(^l'  ,flag)  ; 


} /*  link  to  other  node  */ 

else 

{ /*  link  to  ecu  */ 
pnode  = port->ornoue; 
i£  (chnl'=  pnode->cpoutcnnl) 

{ /*  channel  is  active  */ 

if  ( (ciinl->outbu£)  &S  ( (onode->nf  leit  i OOlfi)  ==  C) ) 

/*  current  channel  has" data  ana  not  rejected  */ 
Dort->p£laq  =1  0100; 

else  /*  current  channel  either  rejected  or  no  data  */ 
{ if  (ncnnl  = finJoutchnl (cnnl) ) 

{ /*  there  exists  ciiannel  with  data  */ 


{ /*  there  exists  ciiannel  with 
pnodo->cooutchni  = nciinl; 
bnoje->nriag  =1  0023;  / 

^ OTrt->p£lag  =|  OlOO; 

else  /*  no  active  channels  */ 
port->p£lag  =&  0277; 


/*  sending  channel  address  */ 


pnO'de->n£lag  =&  0367;  /*  clear  reject  */ 

else  /*  no  active  channel  */ 

port->p£lag  =S  0277; 

/*  if  contention,  resolve  as  before  */ 

if  ( (ijort->p£lag  & 0002)  &&  (port->pflag  s,  0100)) 
{ if  "(flag) 

Dort->D£lag  =S  0375; 
else 

port->p£lag  =&  0277; 


/*  start  new  message  to  controller,  ii  any  */ 

if  ((chnl  = pnode->waithead)  &&  ( (pnode->n£lag  & 0004)  ==  fl)) 
{ pnoae->nflag  =|  0004; 
pnode->waitnead  = ciinl->destc; 


chnl->cClaq  = 1? 


} /*  cpu  link  V 

/*  mark  port  as  visited  */ 
iX)rt->pflag  =|  OUUl; 
if  (p  < portnum) 
op6rt->?flag  =|  0001; 

} /*  pass  1 */ 

/*  FIiSDINCHNL  — this  is  oassed  a non-zero  (Pointer  to  a channel  in  a list  at  a 
port  (a  channel  that  was  rejected  on  the  last  transmission  attemot) . It 
searches  for  the  next  having  <inbuf>  not  zero  and  returns  a oointer  to 
that  channel. 

If  no  channel  with  data  is  found,  it  will  stoo  at  the  original  channel, 
returning  a pointer  to  it  if  it  has  data,  and  zero  if  it  has  none.  */ 

f indinchnl (oc' 

register  struct  chnltype  *oc; 

{ register  struct  chnltype  *cc; 

if  (getnew  ==  2) 
pr intmsg  ( 'g ' ,0) ; 
cc  = oc->nextc; 
while  (cc->inbuf  ==  0) 

{ cc  = cc->nextc; 

if  (cc  ==  ocj  /*  if  none  with  data  */ 
return  ((oc->inbuf)  ? oc  : 0) ; 

} /*  while  V 
return (cc) ; 

} /*  f indinchnl  */ 


/*  FIi.CuUICUhL  — this  routine  functions  identically  to  f indinchnl,  exceot 
that  it  tests  <outbuf>.  */ 

findoutchnl  (oc) 

register  struct  chnltype  *oc; 

{ register  struct  chnltype  *cc; 

pr intmsg ( 'g  ' , 1) ; 

cc  = oc->nextc;  /*  search  for  channel  with  data  */ 
wliile  (cc->outbuf  ==  0) 

{ cc  = cc->nextc; 

if  (cc  ==  oc)  /*  if  no  others  with  data  */ 

^ return  ( (oc->outDuf ) ? oc  : 0); 

return  (cc) ; 

} /*  findoutchnl  */ 
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^include  "s4h" 

/*  GLKERATL  — generate  takes  a oointer  to  a port  and  a copy  of  the  message 
descriptor  painter  from  that  port  and  may  aenerate  a messaqe,  dependinq  uoon 
the  descriptor,  which  may  involve  a random'function.  If  a'messaqe  is 
produced,  a channel  from  tlie  CPU  is  made  for  tne  message,  and  a winter  to  tne 
channel  is  returned  by  generate.  */ 

generate (pport,  desc) 
struct  porttype  *pport; 
register  struct  msdstype  *desc; 

{ struct  chnlype  *chnl; 
register  struct  msgtype  *msg; 
register  int  leafnum; 
int  destination,  offset; 
extern  float  normal (); 

aestination  = 0; 
switcn(desc->dkind) 

{ case  1:  /*  specified  messaqe  V 

if  (desc->il  ==  tick) 
destination  = desc->i2; 
break; 

case  2:  /*  cage  to  non-leaf  */ 

if  (desc->freci  >=  (rand()  / 32767.0)) 
destination '=  (rand()  I (nodenum  / 2))  + 1; 
break; 

case  3:  /*  leaf-to-leaf  with  flat  distribution  */ 

if  (desc->frea  >=  (randO  / 32767.1))) 

{ leafnum  = (riodenum  + 1)  / 2; 
offset  = (randO  ? (leafnum  - 1))  + 1; 
destination  = n + offset; 
if  (destination  > nouenum) 
destination  =-  leafnum; 
else 

it  (destination  < leafnam) 
j destination  =+  leafnam; 

break; 

case  4:  /*  leaf-to-leaf  with  normal  distribution  V 

if  (desc->freq  >=  (randO  /32767.0)) 

{ leafnum  = (nO'denum+  1)  / 2; 

while  (((offset  = (•Jesc->il)  * normal  ())  > (leafnum  / 2) ) II 
(offset  < -(leafnum  / 2) ) li 
(offset  ==  (')) 

^ destination  = n + offset; 
break; 

} /*  switch  V 

if  (destination)  /*  it  itiessage  generated  */ 

{ if  (msg  = freemsg) 

{ freemsg  = msg-dnextm; 
msg->source  = n; 
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n',sg->dest  = destination; 
msq->kind  = desc->mki.id; 
m3g->stime  = tick; 
irisq->length  = desc->:rleng; 
msq->adlcnq  = de3c->aleng; 

^ return (mkchnl (pport,  U,  insg)); 

else 

{ printmsg ( 'n' ,0) ; 
return(C) ; 


} /*  generate  */ 


/*  ^^cUTC  — route  takes  a pointer  to  a TCSsaqe  and  uses  the  global  nod 
to  route  the  nessage  accord  in  i to  tne  algorith-n  s|;x;ci£ied  by'  rtalgo ' . 

struct  chnltype  *route(msg) 
struct  msgtyjje  *msq; 

{ struct  porttype  *^rt; 
register  int  target,  addr.  oldaddr; 
int  value,  dist; 

addr  = n; 

target  = rnsq-Xaest; 
switch (rtalqa) 

( case  1:  /*  sifrple  binary  tree  */ 

it  (target  ==  adar) 
value  = Dortnuif.; 
else 

{ while  (target  > adcir) 

{ oiuaour  = target; 
target  = target  / 2; 

if  (target  < addr) 
value  = (1; 
else 

^ value  = ((oldaddr  & hGtJl)  ? 2 : 1); 
break; 

case  2:  /*  full-ring  (not  fault-tolerant)  */ 

if (target  ==  addr) 
value  = 5; 
else 

{ if  (higher  (target , addr)) 
value  = 1; 
else 

{ while  (higher  (aadr , target)) 

{ oldaddr  = target; 
target  =/  2; 

if  (target  ==  addr) 

value  = ((oldaddr  & 1)  ? 2 : 1); 
else 

{ dist  = mind ist (target,  addr); 


} 


if  ( { ( jist  >0)  ? oist  : 

value  = i); 
else 

value  = ( (dist  > 0)  ? 4 


dist)  >=  5) 
3); 


} 

break:  /*  full-rinq  */ 
/*  switch  */ 


return  (inkchnl  (& (node  [n] ort  [value! ) , ((value  < portnuTi)  ? 2 
} /*  route  */ 


1)  , .Tsq) ) ; 


/*  NOiJAL  — nornal  is  taken  from  C.  Knuth's  Ihe  Art  of  COiTputer  Iroeraming , 
Sominu.nerical  Algorithm.  */ 


float  normal!) 

{ float  r,  r2,  x; 
int  i,  val; 
r ^ 0 • 0 * 

for  (i=i;  i<=12;  i-H-)  r =+  (randO  / 32767.0); 
orintf  ("normal :r;?fii  ,r)  ; 

r = (r  - G)  / 4.0; 
r2  = r * r; 


X = ((((r2 


.029R99776  + 0.00F3559GF)  * r2  + 0.G7G542912) 


* r2  + C.  2524‘JP7t:4)  * r2  + 3.949F4G138)  * r; 
orintf  ("normal ;x:?f*  ,x) ; 
return (x) ; 

} /*  normal  */ 


/*  ?!I.\DIGT  — minuist  is  used  by  the  full-rinq  routing  alaorithm  to  find 
the  lesser  horizontal  distance  between  nodes.'*/ 

minJist(t,  nd) 
int  t,  no; 

{ register  int  m,  s,  value; 
s = t - nJ: 

m = ( (s  > 0)  ? n ; t)  ; 
while  (niqher( — m,  nd)  ==  0); 

;i'++ ; 

if  (s  > 0) 

value  = ( (s  <=  m / 2)  ? s ; (s  - m) ) ; 
else 

value  = ((s  > (-in  / 2) ) ? s : (m  + s)); 
return (value) ; 

} /*  mindist  */ 
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i^include  "s4n" 

/*  FAc32  — rjass  two  is  calico  by  run  for  those  rxsrts  havinq  been  Tarked 
oy  pass  one  as  sending.  For  eacn  node  cither  or  both  of  the  incut  ani 
outbut  oorts  (and  CPU  outout  ixart  for  jqort  nunijer  portnum')  !^iay  be 
sending".  First,  tne  output  port's  senaing  flao  is  checked;  if  sot, 
and  if  the  'send inn  channel  nu.T,ber  bit  is  setl^  no  byte  is  rnoved. 

If  tile  sending  channel  nu.nber  bit  is  not  set,  a byte  is  rroved 

if  tnere  is  room  in  tne  inbuf  of  that  channel,  otherwise, 

the  reject  bit  is  set.  If  th-'  pxirt  is  to  tne  CPU  ano  the  byte  was  the 

last  in  tiie  message,  an  arrival  trace  message  is  outout.  If  the  message 

was  also  a tcardown,  the  channel  is  reiiraved. 

'Ihe  input  port  is  processed  next,  according  to  the  channel  flan. 
It  tne  cnannel  is  waiting  lor  the  controller,  the  byte  is  rejected.  If 
it  is  sending  to  tne  controller,  the  byte  is  moved  into  the  controller's 
buffer;  it  it  was  tne  last  oi  the  address  liytes,  the  message  is  routed. 


_ _ routed 
If  successful,  tne 
indicates 
'outbuf  ' 

Finally,  if  the  port  is  to  tne'CPU,  ttie  CPt'  outout  is  processed 
similarly  to  a regular  output  oort. 


pass2(port) 

I register  struct  oortty’oe  *p;rt; 

( char  *flags,  *flaqo,  *iiufter; 
register  struct  chhltype  *chnl; 
struct  msgtyoe  *ncg; 
reqister  struct  nodetype  *onodo; 
struct  msdstyije  *nidesc; 

pnode  = ix)rt->prnodc; 

/*  process  output  port  */ 

if  {5X3rt->of lag  & ijCiZl) 

{ chnl  = oort->outchnl ; 

if  (*(flago  = & ( ort->,r:tlaq) ) & 091;,)  /*  sending  channel  address  */ 

{*flago)'=&  l;367; 

else  /*  sendino  data  */ 

{ if  (p  < fxirtnum)  /*  non-cpu  rjort  */ 

{ it  (chnl->inbuf  < inbuflim)  /*  room  to  receive  */ 

{ (chnl->inouf ) ++; 

(chnl->outbuL) — ; 

^ pr intmsq { 's' , 1) ; 

else  /*  no  room  — reject  */ 

( (*flago)  =1  0904; 
pr intmsq ( ' f ' ,0) ; 
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} /*  no.i-cpu  port  */ 

else  /*  cpu  port  */ 

{ chnl->outbuf  — ; 
ur intmsg ( ' s ' , 1 ) ; 

if  (++(chnl->inbuf)  >=  (msg  = chnl->cni3g) -> length)  /*  finished  */ 
{ if  (nisg->kind)  /*  end  of  teardown  */ 

rr.ichhl  (port,  P)  ; 

else  /*  end  of  regular  message  */ 

chnl->intuf  =0; 

orintmsg  ( 'a'  ,msa->source,msq->3ti'T’e) ; 

msa->nextm  = free-sg;  V*  return  message  to  free  list  */ 

freemsg  = msg; 

) /*■ message  finished  */ 

^ } /*  ecu  port  */ 

} /*  output  port  V 

/*  process  input  port  V 

if  (port->pflag  s>  finZii) 

{ chnl  = oor t->inchnl ; 
switch (chnl->cf lag) 

case  0:  /*  waiting  for  controller  — reject  */ 
uort->pflag  =i 
printmegCf ' ,2)  ; 
creak; 

case  1:  /*  sending  to  controller  */ 

(chnl->inDuf ) — ; 
printT,sg(  's'  , ; 

if  (++ (cnode->ccnbuC)  >=  (msg  = chnl->cm.sg) ->adlcng) 

{ cnnl->inbuf  =+  pnode->conbuC ; 
pr intmsg ( 'o’ ,0} ; 
cno-Jo->conbut  = h; 
if  (chnl->aestc  = route  (msg)) 
cnnl->cfl''g  = 2; 

else  /*  no  chnl  to  send  to  — wait  */ 
chnl->cflag  = 3; 

^ pnO':ie->nf lag  =&  0373; 

break; 

case  2:  /*  sending  to  outout  port  or  CPU  */ 
if  ( (cl)nl->destc)  is. 

(♦(buffer  = & (chnl->dostc->outbuf ) ) < outbuflim)) 

{ (*buffer )++; 

(chnl->inbul ) — ; 
printm.sq  ( 's'  ,0)  ; 

if  ( (chnl->cnsq->kind)  &&  (chnl->inbuf  ==  0)  &5> 
(chnl->outDuf  ==  0)) 

{ chnl->destc->cir.3g  = cnnl->cmsg; 
rmclinl  (port,  1); 


else 

( port->pflag  =|  0040; 
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/*  reject  */ 


case  3: 


.} 


pr  intir.sg  { ' f ' , 1)  ; 


break: 

r 


break; 

} /*  switch  */ 

/*  input  Dort  */ 


/*  waiting  tor  channel  to  be  created  at  outout  */ 
i£  (chnl-^destc  = route  (cnnl->ciTisql) 
chnl->cfla')  = 2;  7*  successtul  V 

else  /*  still  no  available  channels  — reject  */ 
{ port->pflag  =J  C040; 
printmsqCl'  ,1) ; 


/*  output  fro.n  cpu  */ 

if  ({p  ==  portnu'Ti)  &&  (Dc)rt->D£lag  f.  fillih)) 

{ it  (Dnode->nflag  & 0j2'  ) /*  sending  channel  nuniber  */ 

pn6de->nflag  =&  0357; 
else 

I if  ( (chnl  = pnode->crx)utchnl) ->inbu£  < inbuflim) 

{ (cnnl->inbuf ) ++; 

(chnl->outbuL) — ; 
printrr,sg(  's’  ,2)  ; 

^ (pnoae->cpbytes)++; 

else 

( pnodc->pflag  =|  00.10; 
prinbnsg  ( ' f ’ , 3) ; 
printiiisg  ( 'o'  ,pnode->cpbytes) ; 
pnode->cpbytos  = h; 


} /*  outout  from  cou  */ 

} /*  pass 2 *7 


7*  f’.KCtlNL  — makechannel  takes  a cointer  to  a oort,  an  option  nu.mber,  and  a 
pointer  to  a iriessaae  and  creates  a channel  at  that  oort  for  the  message.  If 
tne  option  "kind"  is  the  channel  is  added  to  those  from  the  CK’,  alter  that 
inaicated  by  cooutchnl" . It  kina  is  1,  tne  cnannel  is  an  outcut  to  the  CPU. 
If  it  is  2,  the' channel  is  an  outcut  to  another  node,  mkchnl  increments  the 
approoriate  channel  count  ann  prints  a message  with  tne  numiber  of  active 
channels.  *7 

struct  chnltypc  *nikchnl  (rx)rt,  kind,  rrisg) 
register  struct  porttype  *!-ort; 
char  kind; 

struct  msgtyie  *misn; 

( register  struct  chnltyjie  *nchnl,  *ochnl; 
struct  chnltype  *head,  *tail; 
register  struct  nodetype  *pnode; 

if  (nchnl  = freechnl)  7*  get  next  avail  free  channel  *7 

( nchnl ->Cinsq  = msg; 
freechnl  ='troechnl->ncxtc; 
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nchnl->outbuf  = nchnl->inbuC  = ncnnl->cflag  = nciinl 
switcli(kind) 

{ case  u:  /*  output  fro.r,  Ci^  */ 

i£  (ocnnl  = (pnocle  = port->ornoJe) ->cpoutchnl) 

{ /*  already  some  active  channels  */ 

(nchnl->nextc  = ochnl->nextc) ->lastc  = nchnl; 
(nchnl->lastc  = ochnl)->nextc  = nchnl; 

else 

{ /*  this  will  be  only  channel  */ 
pno<Je->CDOutchnl  = port->inchnl  = nchnl; 
nchnl->nextc  = nciinl->la3tc  = nchnl; 

^ pnode->nflag  =| 

(pnode->cpchnls)  -H-; 
nchnl->outbu£  = msq->length; 

/*  Queue  channel  for  controller  */ 
i£  (pnoje->waitnead) 

{ /*  already  some  queued  for  controller  */ 
pnode->waittail->.-:estc  = nchnl; 

^ pnode->waittail  = nchnl; 

else 

pnode->waithead  = pnode->waittail  = nchnl; 
break; 

case  1:  /*  output  (x^tt  to  CPU  */ 
if  (ochnl  = port->outchnl ) 

{ (nchnl->nextc  = ochnl->nextc) ->lastc  = nchnl; 
^ (nchnl->lastc  = ochnl) ->nextc  = nchnl; 

else 

{ port->outchnl  = ncnnl->nextc  = nchnl->lastc  = 
^ port->p£lag  =|  0019; 

(port->chnls)++; 

break; 

case  2:  /*  output  port  to  another  macie  */ 
it  (ochnl  = port->outclinl) 

( (nchnl->nextc  = ocnnl->nextc) ->lastc  = nchnl; 
j (nchnl->lastc  = ochnl) ->nextc  = nchnl; 

else 

{ port->outchnl  = ix:>rt->link->incnnl  = nchnl; 

nchnl->riextc  = ncl  nl->lastc  = nchnl; 
j port->pflag  =|  0919; 

(Dor t ->chnl s ) ++ ; 

if  ( (pnode  = port->link->prnode)->waithead) 

{ /*  already  some  queued  */ 
pnO'Je->waittail->destc  = nchnl; 

^ pnode->waittail  = nchnl; 

else 

pnode->waithead  = pnode->waittail  = nchnl; 
break ; 
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ddestc  = 9; 


nchnl ; 


! 

I 


M 


} /*  switch  */ 
return (nchnl) ; 


else  /*  no  channel  free  */ 

{ printiT.sq{ 'n*  ,1) ; 
return(C) ; 

} ^ /*  tnkchnl  */ 

/*  rJ’.CiiNL  — remove  channel  takes  a pointer  to  a port  and  an  ootion  nai.ber  and 
renx5ves  a channel  from  tnat  oort,  and  decrements  the  channel  count.  If  kind  is 
Hr  the  channel  was  to  tne  CPt'.  If  it  is  1,  tlie  alobal  port  number  ’p"  is 
checked  to  see  if  tne  channel  was  from  anotner  ndde  or  from  the  CPU.  */ 

rmchnl(port,  kind) 
register  struct  oorttype  *Djrt; 
char  kind; 

{ register  struct  chnltype  *chnl; 
register  struct  oorttype  *oport; 
struct  node  type  Vnode; 

if  (kind) 

1 /*  not  to  cpu  */ 
chnl  = Dort->inchnl ; 
if  ( 0 '<  portnum) 

( /*  from  external  inout  cort  */ 
if  ( — ((ooort  = oort->llnk) ->chnls)  ==  0) 
port->ihchnl  = Dort->linK->outchnl  = 0; 
else 

{ chnl->noxtc->lastc  = chnl->lastc; 
chnl->lastc->ncxtc  = chnl->nextc; 
if  (oport->outchnl  ==  chnl) 
oport->outchnl  = chnl->nextc; 

. ' 

else  /*frum  cpu  */ 


{ it  ( — ( (pnode  = port->prnode) ->cpchnls)  ==  0) 
Dort->inchnl  = port->prnode->cpoutchnl  = 0; 


{ chnl->nextc->lastc  = chnl->lastc; 
chnl->lastc->nextc  = ciinl->nextc; 
if  (pnode->cpoutchnl  ==  chnl) 
pnode->cpoutchnl  = chnl->nextc; 


else  /*  to  cpu  */ 

{ chnl  = port->outcnnl ; 
if  ( — (port->chnls)  = D) 
port->outchnl  = D; 
else 

{ chnl->nGxtc->lastc  = chnl->lastc; 
chnl->lastc->nextc  = chnl->nextc; 


I 


chnl->nextc  = freechnl; 
Ereechnl  = chnl; 

} /*  rmchnl  v 


ti include  's4h" 


» 


f 


/*  CdllEFiOKr  — otnerport  uses  the  global  node  and  port  (n  & p)  and  returns 
a pointer  to  the  port  attached  to  the  s^^citiod  oort.  The  first  ooeration 
oerforined  is  finding  the  nuniler  of  the  other  node.  A pointer  to  the  ^ort 
can  tnen  be  found  simply.  If  there  is  no  node  attached  or  if  o is  not  valid 
for  the  structure,  zero  is  returned.  */ 


struct  Dorttype  *otherport() 
{ register  int  on; 


if  (p  ==  oortnum) 
retu 
if  (on 


return (1) ; 
= oth( 


/*  if  Ci'U  port,  return  1 */ 


her node  0 ) 

{ switch (shape) 

{ case  1:  /*  simple  binary  */ 
switch (p) 

( case  I):  return  (& (node  (on)  .port  (( (n  & ^001)  ? 2 
case  1:  case  2: 

return  (&  (node (on) .port (C) ) ) ; 

^ default;  rrturn(t)); 

case  2:  /*  full-ring  */ 

switch (p) 

{ case  y;  return (& (node (on) .port (( (n  & RCDl)  ? 2 
case  1:  case  2: 


(nexJe 

on 

.port 

0 

(node 

on 

.bort 

4 

(node 

on 

.port 

3 

; 

case  3:  /*  half-ring  */ 
case  4:  /*  user-defined  4th  link  */ 
switch (p) 

3:  ret  urn  (&  (node  (on)  .exert  (( (n  & 03G1)  ? 2 


( case 

case  1:  case  2: 

return  (& ( 

i(S,( 


} 


cose  3:  return! 
default:  rcturn(l)); 


noue  on 
node  on 


. por 
• Part 


h5l!!l 


^ } /*  switch  (sliape)  */ 
else 

return  (C) ; 

/*  otherport  */ 


1)))) ; 


1)))); 


1)))); 


/*  OfilERNoDE  — othernode  takes  the  global  values  n (node)  and  p (port)  and 
obtains  the  number  of  the  nof.ia  attacned  to  tlic  specified  oort.  if  the  number 
is  valid  (at  least  1 and  at  nost  'nodenum')  it  is  returned;  otherwise  zero 
is  returned,  indicating  that  the  specified  port  is  attached  to  a non-existent 
node.  Most  of  the  values  are  obtained  by  a simple  computation.  */ 

othernode 0 

{ register  int  val; 
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switch (shape) 

{ case  1:  /*  simolo  binary  */ 

switcn (p) 

{ case  0:  val  = n / 2;  break; 
case  1:  val  = n * 2:  break; 
case  2:  val  = (n  * 2)  +1;  break; 
default:  val  = 0;  break; 


case  2: 


case  3: 


case  4: 


break; 

/*  full-ring  */ 
switch (p) 

{ case  5:  val  = n / 2;  break; 
case  1:  val  = n * 2;  break; 
case  2;  val  = (n  * 2)  +1;  break 
case  3:  val  = n - 1; 

if  (higher  (val,  n)) 
val  = (n  * 2)  - 1; 
break; 

case  4;  val  = n + 1; 

if  (Higher (n,  val)) 
val  = (n  + 1)  / 2; 


break  ; 

default:  val  = U;  break; 
break; 

/*  halt-ring*/ 
switch (p) 

{ case  1):  val  = n / 2;  break; 
case  1:  val  = n * 2;  break; 
case  2:  val  = (n  * 2)  +1; 
case  3:  snapc  = 2; 

D = ({n  ^ Ci)01)  ? 4 
val  = othernodeO  ; 


break 
: 3); 


p = ?; 

shape  = 3; 
breaK; 

default:  val  = 0;  break; 
break ; 

/*  user-defin-’d  4th  link  */ 

Switch (p) 

{ case  C:  val  = n / 2;  break; 
case  1:  val  = n * 2:  break; 
case  2:  val  = (n  * 2)  +1;  break; 
case  3:  if  (t-roinpt) 

print! ("liode  %d  is  attached  to  node 
val  = qetnuiTiO  ; 
break ; 

default:  val  = 0;  break; 


break ; 

} /*  switch  (shape)  V , , „ 

return  (((val  <=  nodenuin)  s,&  (val  >=  1))  ? val  : 0) ; 
} /*  othernode  V 
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ifinclude  "s4h" 
/*  PRIMKSG  */ 


printT.sq(k,  a,  b) 
char  k; 

register  int  a,  b; 

{ Svs  itch  (output) 

{ case  1: 

if  (k  ==  't') 

printi ("time  is  ?dr  ,tick); 
else 

{ if  (k  ==  'a') 

printf  ( Tlcsrage  arrives  at  ?d  fro.Ti  %d  since  ?d(!  ,n,a,b); 
else 

{ switch (k) 

{ case  'b';  orintC  (''Eytes  sent  break; 
case  'e':  print£("End  of  run  ' );  break; 
case  'f:  or intf ("Buffer  full,  byte  rejected  '); 
break; 

case  'q':  print! ("Start  new  channel  ");  break; 
case  or intf ("Link  contention  ");  break; 

case  'n':  brint£("f;o  nore  iteTis  ');  break; 
case  'q'-.  printf  ("Channel  created  ; break; 
case  'r':  or intf ("Start  of  run  break; 
case  's':  i^rintf  ("CYie  byte  sent  break; 
case  'x':  Drintf("Lnd  of  session  ");  break; 
default:  .jrint£("%,c  ",k);  break; 

printf  ("at  r.ade  ?d,  port  7d;  ?df;  ,n,p,a); 


break; 

case  2: 

if  (k  ==  't') 

nrintfC'lc  ?d  J '.W  ,k,tick); 
else 

t if  (k  ==  'a') 

printf  ("tc  ' .1  ?d  ?dif  ,K,n,a,b)  ; 

0I30 

printf  ( '^c  7d  %d  ?dlf  ' ,k,n,p,a)  ; 


break; 
) /*  switch  */ 

} /*  printiT.sa  */ 


/*  GL'lwUM  */ 
getnUiiiO 

( register  int  m; 

ID  = 0; 

while  ( ( (c  = qetcharO)  >=  '0')  &&  (c  <=  '9')) 
m = (ni  * Ivhj  + (c  - '()'); 
return (m) ; 

} /*  getnuni  */ 
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/*  HIGliEF  — hiqher  takes  two  node  nu.Tibers  (a  f.  b)  and  returns  tru 
a is  on  a higher  level  in  the  tree  (closer  to  the  root)  than  b)  . * 

higher (a, b) 

register  int  a,  b; 

{ \vhile  ((a  !=  0)  S.&  (b  1=  (')) 

[ a =/  2; 

j b =/  2; 

return ((a  ==  C)  (b  1=  G)); 

} /*  higher  V 


ttinclude  's4h'' 

^uxp ( ) . . 

{ int  1,:; 

Drintfr'  DuT.p  stateii"); 
for  (i=l;i<=nocienu.'ii;i++) 

{ struct  nodetype  *pnodG; 
struct  cxarttype  *Dport; 
cnode  =' & (nodeli] ) ; 

pr  intf  ("  jfUode  ¥d  nflag:?.o  conouf  :?dS  , i,onode->nflaq,pno;3e->conbu£)  ; 
printf("  cpchnls:?d  .vaitn.adrfd  waittail:?d«'  , 

pnode->cpchnls , pno:3e->wai thoad , Dnode->waitta il ) ; 
if  (pnoda-XTsqdssc) 

orintf  ("f'essaqe  descrictor  :?di*'’ ,pnode->;rsgd-3Sc) ; 
if  (pnode->cooutchnl) 
printchnl  (rJnode->cooutcnnl) ; 
for  { j=n;  j<=jx)rtnurri;‘j++) 

{ pport  = & (pnod3->pdrt ( j ] ) ; 
print£("  t-ort  ?d  oflaqitof',  j,  Dport->oflag)  ; 
print£("  qheadr'id"  qtai]  ^d  link:?d?  ', 

pport->qheaa,  pi.ort->qtail,  poor t-> link)  ; 
if  (pport->inchnl) 

{ printf  ('■  Inchannoi ; 
printchnl (pport->inchnl) ; 

if  (poort->outchnl) 

{ pr  ihtf  ( OJtciianncl ; 
printchnl  (pport->outci,ril)  ; 


urintchnl  (chnl) 
struct  chnltyoG  *cnnl; 

{ printf  ("Cnaimel : to  has : if  ' ,ci<nl)  ; 

printf("  nextcixd  lastcrl..  dGstc:?,d  c.Tisq:?off  " ,ciinl->nextc,chnl->lastc, 
cnnl->jostc,  chnl->c nsq) ; 

printfC  outtut:?d  inbut:-d  ctlagrloi!'  ,clinl->outbut ,chnl->inbut , 
cnnl->c£lag) ; 
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STATISTICS  PBDGKAM  COCE 


I 


» 

I 

I 


fdetine  DISTl'lAX  15 
#ciefine  XOCL/IAX  128 
luetine  PORlt-'iAX  6 
jtdefine  CtiNll-lAX  10 
Sdefine  LLX’GTiii-lAX  10 

/*  structure  declaratins  V 

struct  titretype  { float  timesum; 

int  msgnum; 


/*  variable  declarations  */ 


struct  timetype  time  iDlSn-lAX) ; 
int  byteslLLI^GTiuTVX] , 

chnls[NOi:U>iA>;]  li€RiKAX]  , 
active  (CHNU'AX), 
tick,  nuiii,  overflow, 
a,  b,  c, 

nodenum,  portnum,  sha:«, 
char  kind; 


nuLT; 


/*  TAIN  — each  tine  tnis  routine  gets  an  'r'  trace  tressage,  it  will  start 
a new  run.  It  first  oets  trie  f>ara.neters  output  by  'initialize'  in  the 
sirriulator  and  tnen  ge€s  the  trace  output  by  ^run'.  */ 

inain  0 

( 

while  ((kina  = gettraceO)  ==  'r') 

{ getparaivsO  ; 
j runO  ; 

} /*  main  */ 


/*  Ct;'li-Ai>/'vfl3  — ttiis  routine  dovetails  witii  the  parameters  eclioed  by  'init'. 
It  is  not  fault-tolerant  --  if  'init'  detects  bad  innuts  and  prints  out 
error  messages,  'getparar.s'  will  not  be  able  to  handle  them  */ 

yetuaramsO 


/*  get  oucpHJt  format  and  di^oaid  — Lo  be  abbreviated  */ 

printf  ("?d)t"  ,getna-n() ) ; 


I 

I 


/*  get  debugging  level  and  discard  */ 
printf  ("%d#" ,getnum() ) ; 

/*  get  input  and  output  buffer  sizes  and  discard  V 

printf  ("Id#" ,getnum() ) ; 
printf  ("%dS‘'  ,getnum() ) ; 
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/*  get  input  channel  selection  option  and  discard  */ 

print! ("%d#' , getnumO); 

/*  get  nuinber  o£  nodes  */ 

nodenum  = qetnum(); 
print!  ("?d|"  ,nodenaTi) ; 

/*  get  structure  type  V 

snape  = getnuni ; ) ; 
print!  ("%d#  , shape) ; 

switch  (shat^e) 

{ case  1:  portnunfi  = 3;  break; 
case  2:  portnum  = 5;  break; 
case  3;  case  4:  portnum  = 4;  break; 


/*  ignore  characters  indicating  nodes  and  links  killed  */ 

wbile  (putchar  (qetchar  0 ) !=  ' t* ' ) 
while  (putchar (qetchar 0 ) !=  ; 

/*  get  routing  algor ithn  */ 

print!  ("Id#  ,getnum() ) ; 

/*  ignore  .Tx?S3age  descriptor  delinition  */ 

while  (putchar (qetchar 0 ) !=  ’S') 
wnile  (putchar (qetchar 0 ) !=  '»')  ; 

/*  ignore  lengtn  o!  run  V 

print!  ("%djf  ,getnu:r.() ) ; 

} /*  initialize  */ 


/*  PUN  — this  initializes  the  data  structures  and  then  reads  in  th 
trace  and  urxiates  the  structures.  Upon  encountering  an  'e'  ttK?ssage 
it  processes  tne  data  and  outputs  the  results.  */ 

run() 

j register  int  i,j; 

tor  (i=0;i<DIS'niAX;i++) 

{ time  I i] .timesum  = G; 
timefij .msqnum  = G; 

tor  (i=G;i<U:,NGlHt'AX;i++) 
byteslij  = 0; 

£or  (i=l;i<=nodenuni;i-H-) 
tor  (j=n;j<=portnum;j++) 

chnlsdlljl  = 
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overflow  = 0; 

/*  get  trace  messages  up  to  and  including  'e'  — . nd  of  run  */ 

while  (qettraceO  1=  'e') 

{ switch (kind} 

{ /*  depending  upon  kind  of  message,  uodate  structures  aoorooriately  V 


case 


case  'b' 


case  a ' 


case  n 


case  ' t ' 


default: 


/*  arrival  of  message  at  destination 

destination  node  numoer  (ignored),  'b'  h 
in  switches,  and  'c‘  has  the  start  time, 
timelbj .timesum  =+  (tick  - c) ; 

Mtl.r 


'a'  nas  tlie 

has  the  patn  lencth 

V 


js  transmission  of  string  of  bytes,  'a' 
(ignored),  'b'  has  port  (ignored),  and 
ler  of  bytes,  without  channel  numoers. 


has  node,  'b'  has 

*/ 


(titne  (bj  .msgnum)  ++ j 
break ; 

/*  reject  terminates 
has  sending  node  ( 

'c'  nas  the  nuiiuier 
bytes (c)++; 
break; 

/*  message  routed  and  channel  created,  'a' 

!X)rt,  and  'c'  has  total  channels  there, 
chnlsla] (b]++; 
break; 

/*  exhaustion  of  some  free  list,  'a'  and  'b'  are  node  and  sort 
and  'c'  is  kind  of  list,  brint  warninq  message.  */ 
printf("***  List  of  type  ?d  exhausted)!  ,c)  ; 
brintf("  at  no'je  ?d  port  ?d  tine  ?dit  ,a,D,tick); 
break; 

/*  start  of  now  tick,  'a'  i:as  tick  number;  ignore  others.  */ 
tick  = a; 
break; 


ft  cirx  > 

/*  all  other  messaaes  ianored  */ 
bre 


e'eak, 

) /*  switch (kind)  */ 

} /*  while  not  end  of  run  */ 

/*  suLTmarize  statistics  and  print  results  */ 

/*  for  each  tranmission  distance,  print  average  time  and  numlx?r  of  messages  */ 


jr intf ( "Listance 


average  time 


nuiiiber  of  messages#'); 


for  (i=0;i<DIS'lT''/»X;i++) 

printfC  ?d  ¥f  ?d(;  , 

i,  (timelij .timesum  / timeli] .msgnum) , time U) .msgnum) ; 
printf  ("##") ; 

/*  for  each  block  lengtn,  print  number  of  times  that  many  bytes  were  sent  V 

?rintf("l;ua>ber  of  bytes  sent  Numoer  of  occurrences#"); 
or  (i=a);  i<I  i++) 


printf  ("  %d 
printtC'l#")  ; 


?dif  ’, i, bytes (i)) ; 


/*  for  each  number  of  active  channels,  from  zero  up,  print  the  nuriber  of 
ports  having  that  number  */ 
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for  (i=l;i<=nodenum;i++) 
i for  ( j=0;j<=portnuiTi; j++) 

{ if  ((num  = chnlsli][j])  < CiiNLMAX) 
active (num] ++; 
else 

overflow-H-; 

prxntf ("Number  of  active  channels  Number  of  occurrences#" ) ; 
for  |i=0;i<  CliNL.’-'iAX;i++) 

t printfC  Id  i,  activefij); 

printf C^tore  than  Id  channels;  %d  occurrences#',  CIINLI'IAX  - 1,  overflow); 

printfC'End  of  sammary#"); 

} /*  run  */ 


t /*  GEriRACE  — reads  in  one  standard  trace.  Puts  first  (char)  field 

in  'kind'  and  next  three  (int)  fields  in  'a,  'b',  and  'c'.  Returns  'kind'*/ 

qettrace () 

1 kind  = qetchar  () ; 
getchar () ; 
a » getnuird)  ; 
b = getnumi ) ; 
c * getnum  ) ; 
return(kinJ) ; 

) /*  gettrace  */ 

/*  CETNUt'l  — this  reads  in  an  integer  and  reads  the  following  non-digit  */ 
getnum 0 

\ register  int  m; 
register  char  c; 

m = 0; 

while (({c  = qetchar {))  >=  '0')  (c  <=  '9')) 
m = (m  * 10)  + (c  - '0 ' ) ; 
return (m) ; 

} /*  getnam  */ 
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